You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Well, I don't think this would help us much, as xrootd client is reusing once opened connections.
The only problem we have is that, if a client connects to a pool node and (after login) immediate makes an unexpected request (kXR_query, kXR_rm, ...) the pool doesn't know to which door it should redirect the client. If the pool knows from which door the client was redirected, then it can simply respond with a kXR_redirect back to the door.
So, imagine that the door, when redirecting the client to the pool, also includes the door's hostname and port number as a token. If the client presents this information when authenticating (kXR_login) then the pool will always know to which door is should redirect the client, if the client makes a request not supported on the pool.
Sorry, I was being lazy and didn't look at the spec. I see there is a token that the client relays to the pool on redirect. I think it should be easy to update dCache so the door includes its endpoint as this login token. The pool would uses this information to know where to redirect the client, if the client makes a request that is not supported by the pool.
—
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