Hi All,
I posted a query here (5/22/01) concerning problems with rsync on Windows
2000. I want to partially answer my own question, see if anyone has already
solved this problem, and seek additional guidance in designing a fix.
It appears that, when rsync on W2K is the 'sender', the rsync receiver
(regardless of the client platform) terminates with a "Connection reset by
peer" error. Also, depending on the relative speed of the machines and
networks involved, the transaction may or may not complete successfully.
For example, in response to the receiver's request "rsync servername::",
the receiver may display none, all, or some portion of the expected module
list.
Research and experimentation indicates that the cause of this symptom is the
timing and manner in which the sender's socket is closed. The TCP connection
is not shutdown gracefully and any data remaining to be read by the receiver
when the sender's socket is closed is lost. Socket option SO_LINGER with a
non-zero timeout while required for a graceful shutdown, is not implemented.
The 'abortive' shutdown method used to close the sender's socket causes a
TCP RST message to be transmitted on, at least, a Winsock-based platform.
The result of the RST is to abort the transaction at the receiver.
I believe a proper fix would require a modification of the rsync protocol
wherein both the sender and receiver agree (through communication) that the
transaction is complete. This would allow both ends to gracefully close the
connection.
Alternatively, the likelihood of the problem occurring could be reduced (not
eliminated) by implementing a lesser change. This change would add the
SO_LINGER with a non-zero timeout value to the sender's socket options, and
result in a greater probability of the receiver completing its processing
prior to receiving the TCP RST.
What do you think?
Sincerely,
Randy O'Meara
