Print

---

Currently, the f-stream contains binary information that is fixed in size which makes it impossible to add additional fields without disrupting collectors. This proposal attempts to correct this problem. Currently, documented as:

https://xrootd.slac.stanford.edu/doc/dev51/xrd_monitoring.htm#_Toc49119289

Specifically, the XrdXrootdMonFileCLS structure is unchangeable. This proposal would add a length header to each segment of XrdXrootdMonStatXFR, XrdXrootdMonStatOPS, and XrdXrootdMonStatSSQ. The additional members that would be added to front of each each structure would be:

short segLen; // Length of this structure
char segrsvd[6]; // Reserved for future use

Note that segLen restricts the structure to be generally less than 32K-1 which is sufficient since the length of the full record is indicated by XrdXrootdMonFileHdr::recSize which is signed as well.

To indicate that the new format is being used, a new record type would be defined. Currently, this record is tagged as isClose in XrdXrootdMonFileHdr::recType. The new version would have the designation isClose2 so the collector could distinguish which version it is dealing with.

Questions:

1. Should XrdXrootdMonFileHdr::recSize be made unsigned as well as all sub lengths? This would be a more disruptive change should the length of this structure exceed 32K-1 (unlikely to happen any time soon but still). Note that XrdXrootdMonHeader::plen which indicates the full length of the packet which contains these sub-structures is unsigned. Leaving things as they are will unlikely create a problem in the future but it is not technically future-proof.
2. Should there be an option to generate V1 or V2 records? If so, what should be the default?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

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