Print

Print


I got a question regarding the XRootd Protocol Specification version 300 It specifies the kXR_dirlist request format as:

kXR_char   streamid[2]
kXR_unt16  kXR_dirlist
kXR_char   reserved[15]
kXR_char   plen                
kXR_int32  options            
kXR_char   path[plen]

while the Xrootd Protocol Specification version 299 lists the request format as:

kXR_char   streamid[2]
kXR_unt16  kXR_dirlist
kXR_char   reserved[16]       
kXR_int32  plen 
kXR_char   path[plen]

The motivation for the change is clearly the addition of an options field, however the two records as documented in the specification are incompatible Note how the path length field in 299 is at offset 20 and is 4 bytes long, while in 300 is is at offset 19 and 1 byte long

Is this a bug in the specification or is this indeed the intended format? If so, does that mean that xrootd 300 (the protocol) is limited to paths shorter than 255 bytes, and how is a server to provide backwards compatibility with older clients?


Reply to this email directly or view it on GitHub.



Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1