time variable throttling rsync traffic

Andrew Gideon c182driver1 at gideon.org
Wed Sep 16 09:11:35 MDT 2009


On Tue, 15 Sep 2009 22:01:04 +0000, Andrew Gideon wrote:

> It can also potentially be extended in other directions.  For one crazy
> example, the utility (or some other utility that modifies the first
> utilities configuration) could listen on a port for messages from -
> presumably - the receiving server.  That would be a way for the
> receiving server to tell the sender what bandwidth to consume.

Having given this a little more thought, I see issues.  The largest is 
that it requires that the receiving device be able to connect to a port 
on the sending device.  In general, I'd expect firewalls to be a problem.

There's a work around that I think started with the gaming community.  
The sending device needs to send a message to the receiving device which 
causes the sending device's firewall(s) to create an opening through 
which the receiver can then send messages.  

All this is just a work around, avoiding the "real" solution: some way 
for the two intermediary processes - the one invoked via --rsh on the 
client and the one presumably invoked via --rsync-path on the server - to 
communicate over the same SSH stream used by the two rsync processes.

Hmm...perhaps a middle ground is for the SSH process on the sending side 
to permit the receiving device to "talk back" to the sending side via use 
of SSH's -R port forwarding option?

	- Andrew


More information about the rsync mailing list