rsync - Mar 2010 - UDT4 and rsync? support to socket.c?

Hi, has anyone of the devels considered adding UDT4 fast reliable udp 
transport to socket.c, as a user-selectable alternative to using default 
slow TCP?

It could give a 4 to 10-fold throughput improvement to rsync speed over 
wide area networks.

UDT4 is a C++ library. Has been around for a long time. Being C++ this 
might require that a possible new socket_udt.cpp would need a few 
"extern "C"". The UDT4 library replicates the normal BSD
socket API in
UDT:: class context (e.g. getsockopt() becomes UDT::getsockopt() and so 
on). So it is a quite direct drop-in for normal socket ops. API: 
http://udt.sourceforge.net/udt4/index.htm

Just a thought. Has anyone considered it before?  Intention is not to 
replace or enhance the ssh/rsh "--rsh=..." option but the connection
to
a remote rsync daemon.

 - Jan

Jan Wagner wrote:
> Hi, has anyone of the devels considered adding UDT4 fast reliable udp 
> transport to socket.c, as a user-selectable alternative to using default 
> slow TCP?
> 
> It could give a 4 to 10-fold throughput improvement to rsync speed over 
> wide area networks.
If you're seeing that, you must be using an old OS at one/both ends,
or poor TCP settings, or a broken router, or have a very unreliable link.

TCP is generally very good at sustained throughput on WANs, reaching
the network bandwidth limit quickly if there is no congestion, and
sharing it reasonably well when there is congestion.

When it fails, there is usually a fault or silly limit somewhere, and
no assurance that another protocol won't hit the same fault/limit.

What are the bandwidth and delay or your WAN, what OSes are used (with
versions), and what types of connections are involved?

Anyway, if you really want to use UDT4, it is probably better to use a
generic TCP<->UDT4 proxy and point rsync to that.

-- Jamie