 |
 |
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 >>