From owner-freebsd-hackers  Wed Nov  6 08:34:35 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA00357
          for hackers-outgoing; Wed, 6 Nov 1996 08:34:35 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA00351
          for <hackers@freebsd.org>; Wed, 6 Nov 1996 08:34:29 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA08735; Wed, 6 Nov 1996 10:28:42 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611061628.KAA08735@brasil.moneng.mei.com>
Subject: Re: Limiting bandwidth on a socket?  (SO_RCVBUF?)
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Wed, 6 Nov 1996 10:28:41 -0600 (CST)
Cc: jgreco@brasil.moneng.mei.com, hannibal@cyberstation.net,
        hackers@freebsd.org
In-Reply-To: <199611061507.QAA08319@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 6, 96 04:07:40 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > 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