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