 |
 |
Let me try to recap what happens with dCache. Here is a rough schematization of what happens when communicating with dCache:
What is unclear to me is: which open are we talking about? That is, are these TCP connections we are discussing to the door or to the pool? (i.e., what do you mean by "the server")? If they are both the door, then I do not understand why the checksum request ends up going to the pool (it should go to the door, and if that connection has been authorized and the user has permissions on the file, then it should succeed –– that is, checksum requests for arbitrary paths are supported on the door). If they are both to the pool, then the UUID should already be visible to both from the redirect response that a previous open received from the door.
Also, let me correct something I said in my last reply. Even with a UUID shared between the two TCP connections, it is not currently guaranteed that the corresponding mover on the pool will be found, because if the connection which does the open and transfer calls close first, the record of that mover will be deleted. Unlike the door, pools do not have general access to the underlying namespace, but can only serve requests on currently active movers/files. So if the mover is already closed and deleted, even with the UUID things would currently fail because the connection that did not call open did not convey the endpoint from which it was redirected to the pool. Paul has provided a series of patches which "fixes" this situation, provided the login token is used as he discussed.
—
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