 |
 |
Hi Fabrizio, OK, I now understand. Fortunately, switching to using OK_SOFAR is within the protocol spec so there should be a problem here. I'll change this as we discussed at CHEP. I will also provide the additional function which will allow you to specify you only want to see online entries via a flag setting (or would you prefer the flag mean mss entries). Anyway, you'll havethat soon. Andy On Fri, 24 Sep 2004, Fabrizio Furano wrote: > 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 > >> >