I'm a little surprised at this. I use rsync on Win2k every day. Runs
automatically at 1pm in my case, and it hasn't bombed yet. Win2k is the
"sender", receiver is Linux 2.2.13-0.9. Both have rsync 2.4.6. cygwin is
a little old on win2k, uname -a returns 1.1.2. Linux is running sshd
version 1.2.27 without pipes.
Perhaps you mean the problem is in using rsync's internal transport, not
ssh?
On Thu, 24 May 2001, OMeara, Randy wrote:
> 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
>
>
>
--
Robert Scholten Tel: +61 3 8344 5457 Mob: 0412 834 196
School of Physics Fax: +61 3 9347 4783
University of Melbourne email: [EMAIL PROTECTED]
Victoria 3010 AUSTRALIA http://www.ph.unimelb.edu.au/~scholten
