Print

---

Hi Andy,

We have discussed a couple of concepts/ideas on our side of the pond and I am going to try to write them down for you here is in this ticket/issue.

Briefly the two concepts/ideas are:
* Your server side fix of checking for mutual exclusivity before truncating a file won't work for small files. 
* We're try to find a TCP/IP option that will guarantee on the client side that a connection to the server is truly "dead" before creating a brand new TCP/IP connection.

Going into more details with your server side fix in XRootD 4.8.2 RC2.  The server will now reject a concurrent "open the file and truncate" request when there is an on going file transfer.  This is great for relatively long files.  Eric has pointed out that very small files will not be protected however.  Here is the scenario with XRootD 4.8.2 RC2:
1. XRootD client sends a "open file and truncate" request to the server.
1. The corresponding TCP/IP packet gets dropped/lost.
1. The XRootD client library times out and closes the TCP/IP connection.
1. The XRootD client library opens a brand new connection to the server.
1. The XRootD client completes the entire transmission of the small file to the server (open , write, write... and then close).
1. The lost "open file and truncate" TCP/IP packet gets retransmitted by the TCP/IP stack underneath the XRootD client library.
1. The server lets the request take the mutual exclusion lock on the file for writing.
1. The server truncates the file.
1. The server receives the FIN packet of the close request on the connection made ages ago by the XRootD client library.
We're done, the small file has now been truncated.

Going into more details about making sure the TCP/IP connection is really closed on the client side before creating a new one.  We believe the first request to "open and truncate" the file is being replayed by the TCP/IP stack underneath the XRootD client library, even after the library has called `close()` on the connection's file descriptor.  Eric has looked at some TCP/IP socket options and thinks there is a way to guarantee the connection is really closed before opening a new one.  Eric sent the following e-mail to us here at CERN:
```
Maybe we could play with this (man 7 socket):
 
 
       SO_LINGER
              Sets or gets the SO_LINGER option.  The argument is a linger
              structure.
 
                  struct linger {
                      int l_onoff;    /* linger active */
                      int l_linger;   /* how many seconds to linger for */
                  };
 
              When enabled, a close(2) or shutdown(2) will not return until
              all queued messages for the socket have been successfully sent
              or the linger timeout has been reached.  Otherwise, the call
              returns immediately and the closing is done in the background.
              When the socket is closed as part of exit(2), it always
              lingers in the background.
 
 
Cheers,
Eric
```

-- 
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-374563256

########################################################################
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