Problems with --bwlimit && --daemon

[Marcelo Ricardo Leitner]

On Fri Nov 05, 2004 at 09:57:23 -0800, Wayne Davison wrote:
> On Thu, Nov 04, 2004 at 12:26:06PM -0200, Marcelo Ricardo Leitner wrote:
> > The problem is that on io.c:882 bwlimit_writemax is also used to
> > control the bandwidth, but it is not initialized for the daemon mode.
> 
> That's because --bwlimit is a client option.  The current code in CVS,
> which now prevents the the user from mixing daemon options with client
> options, doesn't even let you specify --bwlimit in combination with
> --daemon.  I am considering making --bwlimit a daemon option, but the
> older rsync code would always override the server's value with a value
> specified by the client, so this was just a default bwlimit for each
> transfer, and not an enforced limit.

Ouch! I have never noticed this, although the manpage doesn't even mention it:

       --bwlimit=KBPS
              This option allows you to specify a  maximum  transfer  rate in
              kilobytes  per  second. This option is most effective when using
              rsync with large files (several megabytes and up).  Due  to the
              nature  of  rsync  transfers,  blocks  of data are sent, then if
              rsync determines the transfer was too fast, it will wait before
              sending  the  next data block. The result is an average transfer
              rate equaling the specified limit. A value of zero specifies no
              limit.

> Thoughts?  Were you expecting the daemon-specified bwlimit to be just a
> default or a maximum limit?

A maximum limit. Imagine a mirror site saying to the user: "Hey, if you are
on broadband, please, be sure to use --bwlimit lower then 150 otherelse
you will grab all our bandwidth!"

It would be pretty nice if this work for both sides.
Maybe clients should override the server's value only with lower values?
And thus allowing both sides to control their traffic. Well, this defines
your maximum limit idea.

---end quoted text---

Thanks for your time,
-- 
Marcelo Ricardo Leitner <mrl at conectiva.com.br>