> Well, I do not understand completely. Here is the actual behavior:
> - We have two strings that can be passed by a kxr_redirect:
> - a "login" token which will be passed to the dest server in the login
> phase and then cleared
> - an "open" opaque info which will be passed to the dest server in the
> open phase. This is not cleared, but can be overwritten by a subsequent
> This is the way I interpreted the proto specs. How does it sound to you?
I interpreted the behavior in the same way, but some questions remain:
Is there a destinction in the kxr_open request between opaque data
coming from a redirect and opaque data to steer the open (as found in
section 3.12.1 of the spec)?
Is the "redirect opaque data" appended to the filename with a "?" in
between or do we need an additional "&" as written in the spec?
Must the "redirect opaque data" be ASCII or can it be binary too?
The reason why I'am asking all this is that we are working on a xrootd
mover in dCache. Currently, the client connects first to a known xrootd
door which then causes the redirect towards a xrootd mover, from where
the file transfer is performed. The current prototype works
rudimentarily with TXNetFile, but passing opaque data along the
kxr_redirect would be a great help for better syncronization between
door and mover.
For those who are going to be in Mumbai, Patrick and Tigran will talk
about this for sure.