 |
 |
@abh3 : Your solution will solve the real problem (making sure the current connection will not retransmit anything before starting a new connection), but the timing will be very dependent on retransmissions in the TCP stack. As we saw, it sometimes takes minutes before the 1st open get retransmitted and corrupts the file, so the retry would take that amount of time in those situations (open will have to go through on the 1st TCP connection anyway before the endsess command goes through). My proposed direction of investigation (as this linger option has not been tested in any way besides RTFMing) has the drawback that it might not be portable to all client architectures. Overall, the client must never have 2 path to the server open at the same time, so both solutions would fit the bill. I have a slight preference for the linger solution as it will allow more aggressive retries (when we recall from tape with the computer center, we could have on open timeout of only 10s of seconds if not seconds, as the usual RTT is very small). In our case, this would prevent wasting tape drive bandwidth. We only have ~3 minutes of in-memory buffer in the tape servers, so blocking for that amount of time will eventually waste drive resources. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/673#issuecomment-374857063 ######################################################################## 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