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

From: Yar Tikhiy (yar_at_comp.chem.msu.su)
Date: 01/15/05

  • Next message: Luigi Rizzo: "Re: Socket rate limiting (was: Re: making nmdm(4) emulate actual speed.)" 
    Date: Sat, 15 Jan 2005 13:36:07 +0300
To: Luigi Rizzo <rizzo@icir.org>

    On Mon, Jan 03, 2005 at 06:57:16AM -0800, Luigi Rizzo wrote:
    > On Mon, Jan 03, 2005 at 11:47:39AM +0100, Poul-Henning Kamp wrote:
    > >
    > > I participated in an "Editor Celebrity Death Match" recently and
    > > being the senior combatant my weapon of choice was ed(1). To
    > > properly show off ed(1)'s main weakness I wanted to run my slides
    > > in ed(1) on a 300 bps line.
    > >
    > > Rather than use two USB-serial dongles and a usb-hub, I hacked nmdm(4)
    > > up to actually respect the baud-rate set with stty.
    > >
    > > Would this be considered generally useful ?
    >
    > being nmdm(4) an emulation tool, i'd say definitely yes, probably
    > even more useful if you provide a knob to enable/disable the speed
    > emulation -- i see a point in actually emulating the wire speed,
    > but also one in not doing so when the application is not speed-sensitive
    > and you just want it to run quickly.

    Seeing so many smart folks contributing to this thread, I can't
    help raising a related question, which has been gnawing at me for
    quite a while :-)

    A lot of network daemons implement rate limits by their own. For
    instance, Apache httpd has mod_throttle, Squid has delay pools, and
    even lukemftpd has some sort of rate limiting code in it. With the
    demand for rate limiting being so high, it could be natural for an
    OS to provide such service to applications through, e.g., a per-socket
    option.

    However, I've got an impression from the first glance at the issue
    that it would be next to impossible to implement such service in a
    fashion independent of lower layers of network abstraction. I
    suppose that we have such elaborate and IP-centric subsystems as
    DUMMYNET and ALTQ partly because of the complexity of the task.
    Therefore a possible approach is to implement the rate-limit socket
    option using one of those existing subsystems. Such solution would
    scale poorly though--imagine a server with thousands of rate-limited
    sockets open, each of them requiring a separate DUMMYNET pipe. Did
    anybody have other thoughts or see publications regarding the
    problem? 

    -- 
Yar
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Luigi Rizzo: "Re: Socket rate limiting (was: Re: making nmdm(4) emulate actual speed.)"