rsync versions: all known
socks5 hangs while trying to do rsync through it. So does plug-gw
from fwtk.
There is one peculiarity in rsync protocol. It even occurs not on
every rsync module, only while trying to do something like:
rsync -avvz cvs.xemacs.org::xemacscvs/XEmacs/xemacs/ ./
In rsync both client and server may send bulk data to each other in
the same time on the same connection. In contrast, in other protocols
there is usually some sort of dialogue between client and server: one
party sends, other receives.
Server read buffer may even get filled (tcp window will zero) and data
transfer to server stops, but data transfer to client continues. This
works perfectly on direct tcp connection. But socks5 blocks while
trying to write to server and never passes data to client. So rsync
client times out and fails.
When rsync client does not send much data, in particular, when user
specifies only few files to download, and server read buffer is not
filled, rsync works normally.
It is certainly bug in tcp level gateway, but it seems to be very
common. Fixing gateways running on firewall is not always feasible.
So is changing rsync server behavior (increasing read buffer). So
making a workaround of it in rsync may be reasonable. There is
certainly some correspondence in rsync protocol between (bulk) data
being sent and received by client. There should be a way to specify
to rsync client not to send more than that many data ahead of those
"acknowledged" by responses from server, so that server read buffer
will never get filled.
A more radical solution is changing rsync protocol to use 2 different
tcp connections like ftp protocol does.
I am not on the mailing list.
