 |
 |
Hi Thomas, Not quite. There are two TPC modes available: 1) Regular tpc that uses a rendezvous token between all the parties. Once the rendezvous is completed the data flow from sourc to sink. The client is out of the loop. 2) Delegated tpc where the client delegates it's credentials to the sink which then uses it to pull data from the source. Again, other than delegating the credentials, the client is out of the loop. Here ae some relevant client-side scenarios (note these are not the only ones possible but these cover the tpc part): a) When you specify --tpc first you are saying that you prefer the rendezvous kind of tpc but will sttle for a copy through the client if tpc can't be done. b) If you specify --tpc only then you are saying only rendezvous tpc will do and fail the copy if it can't be done that way. c) If you specify --tpc delegate only then the client will try delegation first and if that fails revert to using a rendezvous token. If that fails, the copy fails. Clear? Andy On Mon, 6 Apr 2020, Thomas Hartmann wrote: > Hi Any, > > many thanks for the clarification - I think I have a clearer picture now ;) > > So, 'full' third party copies are initiated with '--tpc delegate', i.e., > requesting a token from the source/sink and delegating it to the sink/source, > so that it can initate the actual transefr. > > With '--tpc' only it is closer to a direct server-client copy and the token > is just used to authorize against the pool but the transfer is server-client? > > And 'only' acts for both as ratchet against falling back to pre-tpc. > > I hope that I got this right ;) > > Cheers and thanks, > Thomas > > On 04/04/2020 01.36, Andrew Hanushevsky wrote: >> Hi Thomas, >> >> Just to clarify; when you say "--tpc delegate only" that applies to the >> "tpc" part not the "delegate" part. So, if delegation fails, the client >> tries to do a standard TPC. We did it that way to keep backward >> compatability. >> >> Andy >> >> >> On Fri, 3 Apr 2020, Thomas Hartmann wrote: >> >>> Hi all, >>> >>> we are currently updating the dCache instances in Wupeprtal and DESY-HH to >>> be xrootd TPC ready. >>> >>> We started with Wupeprtal and experience some problems where third party >>> copies 'in one direction' work but fail in the other. >>> >>> From the debug output, I assume that the difference between >>> --tpc only >>> and >>> --tpc delegate only >>> is like for HTTP TPC PUT vs. GET, i.e., if the Source or the Sink create >>> the proxy and the other end point uses the proxy info to copy to/from, or? >>> >>> The working copy >>> Wuppertal --> DESY-HH with --tpc delegate only >>> https://desycloud.desy.de/index.php/s/R2ZoQfENEqe8ixD/download >>> seems a bit odd, as first an authz handshake with the DESY-HH node seems >>> to fail due to a denied permission. >>> And then falls back to "a third party fall back copy job", where it seems >>> to request a TPC token from the Wupeprtal node. At the DESY-SE the client >>> gets properly redirected to the pool dcache-dot18.desy.de, which has a >>> 'TPC lite' support - what does that mean actually ?? >>> After whcih the transfer is actually started >>> >>> >>> The failing copy >>> Wuppertal --> DESY-HH with --tpc only >>> https://desycloud.desy.de/index.php/s/kGtefD6qN2H8qGR/download >>> starts apparently also handshaking with the DESY-HH node first - before it >>> also(??) falls back to a "third party copy job" but mentions "We are NOT >>> using delegation" ? . >>> The client again is redirected to a sink pool dcache-dot23.desy.de but >>> fails then due to a" Permission denied". >>> >>> Is this permission denied due to the token not being accepted by >>> dcache-dot23.desy.de or because the client authz fails to request the >>> actual token? (but then why does the client mentions that it is not using >>> delegation? ?) >>> >>> Long story short: at which end of the two instances do we have an >>> autghz(?) problem >>> >>> Cheers and thansk for any ideas, >>> Thomas >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1