wiki:SrmChangesForXrootd
Last modified 8 years ago Last modified on 03/03/10 12:24:49

NB. THIS IS NOT A dCache PROPOSAL!

I'm trying to clearly capture what changes are proposed by other people so everyone can agree and we can implement what is required.

GLUE

  1. An SE that supports the xrootd protocol will publish a GlueSEAccessProtocol object that represents this support. This is NO CHANGE from current behaviour.
  2. This GlueSEAccessProtocol object must be published with a GlueSEAccessProtocolType attribute. This is NO CHANGE from current behaviour.
  3. The value of this GlueSEAccessProtocolType will be xroot. This IS a change from current value: root.
  4. An "SE that does not implement the redirection part of the xrootd protocol" (from Brian), or "only an 'xroot door' and not a pure xroot implementation" (from Installed Capacity), or however one wishes to phrase this must not publish a GlueSEControlProtocol object with GlueSEControlProtocolType = xroot. This is NO CHANGE from current behaviour.

SRM

  1. The SRM's API will accept a protocol value root with srmPrepareToGet to indicate the client understands the xrootd protocol. This is NO CHANGE from current dCache behaviour. (This is needed for backwards compatibility.)
  2. The SRM's API will accept a protocol value xroot with srmPrepareToGet to indicate the client understands the xrootd protocol. This IS change from current dCache behaviour.
  3. When the client's srmPrepareToGet request is satisfied by their root protocol keyword (see 5. above) then the SRM will return TURLs that start root://. This is NO CHANGE from current dCache behaviour. (This is for backwards compatibility)
  4. With the client's srmPrepareToGet request is satisfied by their xroot protocol keyword (See 6. above) then the SRM will return TURLs that start xroot://. This IS a change from current dCache behaviour.

xrootd door

  1. The xrootd door will accept root:// as an envelope URI (containing security information from the xrootd catalogue). This is NO CHANGE from current behaviour.
  2. The xrootd door will accept xroot:// as an envelope URI (containing security information from the xrootd catalogue). This IS a change from current behaviour.