time variable throttling rsync traffic
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?
More information about the rsync