 |
 |
Issuing a separate request to the pool endpoint, however, is currently not going to work, because it is lacking the UUID for the transfer generated on open at the door, and also because the new connection does not indicate where to redirect (which door), information also obtained from the original open request, which is not present.
@alrossi : from the comment above I gather that the UUID is generated only on open, is this correct? If yes, there's no mystery, the open is issued only on one of the connections so the other cannot have the token.
This is what is happening in xrdcp (but also what could happen with any experiment framework using CopyProcess):
before using the CopyProcess the client is doing a stat, this creates a physical connection 1 to the server
then the client is using CopyProcess to carry out the transfer, since this is a TPC and the CopyProcess doesn't know if the server will require it to be encrypted, it has to open a second physical connection, call it connection 2, that is dedicated to TPC, using this connection the file is being opened, transferred and closed
afterwards, the client is issuing a query checksum request, which technically is not part of TPC so before 9fb8851 it was using connection 1 that, I suppose, does not have the UUID token because there was no open done on this connection
Now, the big question for me is: why does the query checksum request requires the UUID? It is a stateless request, it shouldn't require the file to be opened.
—
You are receiving this because you commented.
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