From owner-freebsd-hackers Wed Oct 4 09:29:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA24880 for hackers-outgoing; Wed, 4 Oct 1995 09:29:18 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA24875 for ; Wed, 4 Oct 1995 09:29:16 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA11600; Wed, 4 Oct 1995 11:19:42 -0500 From: Joe Greco Message-Id: <199510041619.LAA11600@brasil.moneng.mei.com> Subject: Re: A moment in the life of ftp.cdrom.com To: gary@palmer.demon.co.uk (Gary Palmer) Date: Wed, 4 Oct 1995 11:19:42 -0500 (CDT) Cc: msmith@atrad.adelaide.edu.au, CACHO@mexicano.gdl.iteso.mx, taob@io.org, hackers@freefall.freebsd.org In-Reply-To: <1492.812770019@palmer.demon.co.uk> from "Gary Palmer" at Oct 4, 95 02:26:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk > Michael Smith stands accused of writing in message ID > <199510032321.IAA14949@genesis.atrad.adelaide.edu.au>: > >> I think microsoft has won that race, their ftp system told me to go > >> away last week, they had 1250 ftp users on line. > > >Yah, but have you tried to use it past the 600 mark? Whatever it is just > >loses its marbles as far as long-distance connections are concerned. > >(At least, that's been my experience) > > The problem is what network link you have really. If you can get a > fast enough network connection (perhaps FDDI or 100bTX), you should in > theory be able to handle that number without TOO many problems. Of > course, you'll always have problems with people a couple of hops away > on a fast link swamping your network :-( > > Anyone know a way to do traffic limiting? Is it even fair? About a year ago, we had a (*cough*) product related issue where we were arguing for the use of TCP/IP and tftp and another group was arguing for the use of some propietary blinkywink protocol - the advantage of our proposal was that you can go get an arbitrary TCP/IP implementation for a PC, workstation, etc., at the corner store, while a custom blinkywink protocol is something we have to write and is probably only available from us for a single platform. The argument: "tftp cannot be throttled." (the data being transferred was code to be written to a slowish flash RAM card, and there were concerns about the retry times, etc that I don't quite recall). My answer: "Rubbish", and I promptly added a "sleep()" call right after the data read. Wow did that ever do wonders to slow the transfers. :-) You should be able to bandwidth limit any arbitrary connection with a similar concept - it's fast, easy, simple to implement, stupid, and on top of it is not hard on the system. You probably want to be a little smarter than just sticking a fixed-length sleep(), but essentially that is all you NEED to do. You can write a little wrapper that allows X bytes per second through in a given period of time... I also wrote, at one time, a simple "throttle" program that limits bandwidth by malloc()ing a buffer of however many bytes per second I wanted to allow (something like 1KB to 1MB/sec) and sleep(1)ing after each read/write sequence. This is a little more efficient, maybe, when you want to limit bandwidth at high rates of speed - less syscall overhead, but potentially less accurate (it WILL limit you to something LESS than what you specify). Both techniques are trivial to code. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Software Engineer, UNIX/Network Hacker, Etc. 414/362-3617 Marquette Electronics, Inc. - R&D - Milwaukee, WI jgreco@mei.com