Socket rate limiting (was: Re: making nmdm(4) emulate actual speed.)

[Yar Tikhiy]

On Sat, Jan 15, 2005 at 02:49:30AM -0800, Luigi Rizzo wrote:
> two comments: the reasons why apps implement throttling on their
> own are
> 1) portability - they cannot assume the required services
>    are available on the platforms they are going to run on;

Software (stock daemons in particular) could benefit from having
such service through using some kind of #ifdef'ed code.  AFAIK, the
notorious Apache httpd uses accept filters and sendfile() this way.

BTW, it's a partucularly important case that an application can't
use sendfile() and do throttling at the same time w/o support from
the OS.

> 2) scheduling and resource management - apps have their own
>    requirement on how to schedule things and it is often
>    unlikely that they can express them in term of altq/dummynet
>    "classes".

Such OS-level rate-limiting service could be the "lowest common
denominator" for simpler net apps that just want make sure a client
won't get more than X bps of traffic.  Then it can be extended to
hierarchic classes of clients, e.g., impose an overall limit on all
sockets stemming from a single listening socket etc.

> This said, there is no problem in having thousands of dummynet
> pipes -- the algorithms used in dummynet have O(log N) cost
> where N is the number of active pipes.

Thank you for your considerations!

--
Yar