Date: Sat, 15 Jan 2005 13:36:07 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Luigi Rizzo <rizzo@icir.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Socket rate limiting (was: Re: making nmdm(4) emulate actual speed.) Message-ID: <20050115103607.GA81277@comp.chem.msu.su> In-Reply-To: <20050103065715.A67451@xorpc.icir.org> References: <18962.1104749259@critter.freebsd.dk> <20050103065715.A67451@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050115103607.GA81277>