Date: Wed, 6 Nov 1996 10:28:41 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: jgreco@brasil.moneng.mei.com, hannibal@cyberstation.net, hackers@freebsd.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) Message-ID: <199611061628.KAA08735@brasil.moneng.mei.com> In-Reply-To: <199611061507.QAA08319@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 6, 96 04:07:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I could swear I saw a "low-bandwidth ncftp" or something of the sort on
> > > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at
> > > least in Linux...). It's apparently been deleted though.
>
> Some ftp sites (e.g. funic.funet.fi) tell you the amount of bandwidth
> that has been allocated to your ftp connection. Try to look at what
> kind of ftp server they use.
The ones I have seen implement this with a sleep() mechanism.
> > I am not aware of any general way to do this without code modifications,
> > without the introduction of specialized code such as ET's bandwidth
> > manager (and I am by no means certain that BWMGR can handle this).
>
> I think to remember this was discussed some time ago on the hackers list.
> Unfortunately I don't remember the outcome of the discussion.
Yeah, and I think I mentioned the sleep() thing last time too.
> If you work inside the kernel (see the 'dummynet" stuff in my
> home page, it introduces bandwidth limitations on your link; with a
> little effort it can be configured to set different limitations on
> different TCP/UDP ports), you can avoid modifying program sources,
> which is extremely annoying.
Yes, absolutely agree (at least for end users).
> Otherwise, for servers which are launched
> by inetd, perhaps you can add a bandwidth-limiter process between your
> process and the socket and again avoid having to modify sources.
> Perhaps tcp_wrappers do this ?
I do not know. I have a tool that could perhaps be used in this sort
of application, however...
I have a little gimmick called "throttle" which accepts an argument of "K"
that accepts input on stdin and outputs on stdout, and guarantees that a
maximum of "n" K per second goes through it.
It is a really trivial algorithm, and it is important to realize that the
guarantee IS a maximum, but actual throughput may be substantially less.
All it does is
size = 1024 * argv[1]
mem = malloc(size)
while (data) {
read(mem, size, stdin)
write(mem, size, stdout)
sleep(1)
}
"Duhhhhmb" but works. One could go to a very small bit of work to make it
bidirectional, more suited to general inetd-type services.
> > I will note that some PPP/SLIP software allows prioritization of certain
> > types of traffic, by way of "TOS" (type of service) queue reordering.
> > This works moderately well when the MTU is small and the amount of data
> > being buffered by the modem is very small. Cheap modems generally do not
> > give you that level of control.
>
> I don't think the modem takes more than 128-256 bytes of data, so
> packet prioritization inside the PPP sw can serve the purpose.
I have seen modems which appear to buffer well over a kilobyte of data..
... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611061628.KAA08735>