Argh.
My problem is that this kind of structure violates the structure
described in par. 2.4 where a single dlen-data chunk is supposed to exist.
Since the client code (any client version) has been built on it, i
expect that the stream hangs if an answer to kXR_dirlist arrives. Is it
so problematic to pack the answer in a single data block using some
end-of-string separator (maybe 0)? Well, if you have to list 10E255
files it might be the case, but in this case we could send the filenames
e.g. 10-100-1000 at a time using the kXR_oksofar mechanism with a
reasonable buffer length.
What do you think?
Fabrizio
Andrew Hanushevsky wrote:
> Hi Frabrizio,
>
> This is the messy case where ints do not fall on word boundaries, so you
> have to do the allignment yourself. The stream is basically, four bytes of
> length followed by characters of that length. This is repeated until the
> four bytes of length are zero. To receive this successfully, you need to
> do partial reads from the stream. So, do a read of 4 into an int (so it's
> aligned), unmarshall it, use it to read that any bytes into a char buffer.
> Repeat until you get a length of zero.
>
> The problem here is that there is no convenient way that the server could
> figure out how many bytes would be transmitted ahead of time. It could use
> the OK_SOFAR protocol but that would be very ineffecient. So, the server
> pices the stream together in real time. That's why it is the way it is. I
> suppose we could change it by indicating in the request that you want to
> use OK_SOFAR protocol, but is it really necessary?
>
> Andy
>
> On Fri, 24 Sep 2004, Fabrizio Furano wrote:
>
>
>>Hi Andy,
>>
>> I don't understand the format for the DirList response from xrootd.
>>The protocol spec says that the response has the following format:
>>
>>kXR_char streamid[2]
>>kXR_int16 0
>>kXR_int32 dlen
>>
>>kXR_char dirent[dlen]
>> ?
>> ?
>> ?
>>kXR_int32 0
>>
>>But how can I manage to parse a response where all the dir entries are
>>just juxtaposed?
>>
>>Fabrizio
>>
|