rsync 2.4.6 hanging on HPUX11 only over firewall.

[Wayne Davison]

On Mon, Dec 09, 2002 at 01:49:40PM +0000, rsyncuser wrote:
> We are interested in finding out whether the wayne-nohang patches can
> be applied to 2.4.6. 

My older patches for 2.4.6 had got moved aside after they got
incorporated into the main distribution.  However, I just put them back
in their original spot so they can be accessed again.

The most important patch was the simplest:

    http://www.clari.net/~wayne/rsync-nohang1.patch

This patch ensures that data coming from the generator to the sender
does not overflow and block during the final phase of the transfer on
the sending side (but not necessarily at the final file, due to the
buffering on the outgoing connection).  The current code waited around
for the remote process to end without reading the incoming data stream,
which was a very bad idea if the -v option was turned on.

The second patch fixed a much rarer bug -- one that should only get
tickled if a good number of the files fail to transfer correctly on the
first try and need to be resent:

    http://www.clari.net/~wayne/rsync-nohang2.patch

An older version of this patch was included in the Red Hat sources for a
while, so it was pretty widely tested:

    http://www.clari.net/~wayne/old/rsync-nohang.patch

(Note that this patch contains the "nohang1" patch as well.)

The reasoning behind this patch is that there is a data channel from the
receiver to the generator that tells it what files to retry.  This data
channel is left totally unread until all files are handled in pass 1.
This means that it can block if enough files need to be resent.  My
patch keeps this data channel clear by reading it whenever data appears
and setting flags on what files to resend during the retry phase.

I'm thinking about writing a new patch for the latest rsync that causes
these need-to-retry files to be immediately resent by the generator to
the sender instead of buffering them (with proper signaling to ensure
that retry files get their alternate block-sizes set).  Perhaps this
solution would finally allow this bug to be put to rest (since it's not
yet fixed in the main code).

..wayne..