Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Nov 1996 12:31:47 -0600 (CST)
From:      Joe Greco <jgreco@brasil.moneng.mei.com>
To:        rminnich@Sarnoff.COM (Ron G. Minnich)
Cc:        hackers@freebsd.org
Subject:   Re: Limiting bandwidth on a socket? (SO_RCVBUF?)
Message-ID:  <199611061831.MAA08899@brasil.moneng.mei.com>
In-Reply-To: <Pine.SUN.3.91.961106095628.29356E@terra> from "Ron G. Minnich" at Nov 6, 96 10:05:50 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > int s, rval;
> > s = socket(...);
> > while ((rval = read(..., 1024)) > 0) {
> > 	sleep(1);
> 
> ooch, ouch. my brain now hurts :-)

Whazzamatta?  Don't tell me you have never executed a gross hack before!!

> Joe's method will work fine, but we may all agree we want a little more. 
> Well, we're working on that here. So I would like to judge interest from 
> this group. 
> 
> What we're looking at is putting ioctls in at the socket layer to
> implement rsvp-style reservations. I.e. you would use rsvp as now for
> reserving qualities related to flow of data, and our code would operate at
> the socket layer for enforcing those reservations. We want it to be at the
> socket layer so the user can have the controls work the same even though a
> socket may at the lower level be unix-domain, tcp, and so on. We've found 
> that this sort of control is very important for distributed computing. 

That is nice at an upper level, but I can see at least as much usefulness
at a more administrative level as well.

A particular application may certainly know that it wishes for bandwidth 
of 'X' and it can arrange that through some mechanism.  A socket level
mechanism can provide a maximum cap, certainly...

However, it would also be nice to be able to deal with this at the network
level, and while some things are already available to allow this (ET's
bandwidth manager for example), it would be something that I recommend you
at least consider and be aware of.

... JG



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611061831.MAA08899>