Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jun 2002 19:09:05 -0400
From:      David Gilbert <dgilbert@velocet.ca>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Giorgos Keramidas <keramida@FreeBSD.org>, Wouter Van Hemel <wouter@pair.com>, hackers@FreeBSD.org
Subject:   [hackers] Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Message-ID:  <15639.42641.410043.846076@canoe.velocet.net>
In-Reply-To: <3D13BF30.565B7A53@mindspring.com>
References:  <20020621000924.GA2178@hades.hell.gr> <3D129CA8.EFADA4FF@mindspring.com> <1024656206.277.9.camel@cocaine> <3D13A4DA.28F3B169@mindspring.com> <20020621235847.GE5836@hades.hell.gr> <3D13BF30.565B7A53@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Terry" == Terry Lambert <tlambert2@mindspring.com> writes:

>> Actually I was thinking more of ReGet and Godzilla-style software
>> used by some users to play unfair and suck more bandwidth out of an
>> FTP server, by opening a zillion sockets and downloading a single
>> file in chunks.

Terry> What a clever hack!

Terry> I don't know if I should revise my argument to include
Terry> per-IP-per-file, which would of necessity be user space, or
Terry> just admire it and say they *deserve* more bandwidth for being
Terry> smart...

... and axel for FreeBSD.

I think this is another example of the iternet routing around
problems.  The problem is that small amounts of packet loss (etc) make
is amazingly good to take the multiple stream approach.  I believe
axel's default approach is to open 4 connections.  With the FreeBSD
ISO, I get 100 to 250 KB/s with regular ftp (depending).  With axel, I
get 550 KB/s (on a 100M well-connected link).  In fact, the worse one
connection does, the more reason to get out the multi-connection tool.

There are only two ways to attack this problem: make it less
profitable or impossible.  Making it impossible will catch all kinds
of people in the same net.  Making it less profitable will make the
problem go away by itself.

The only idea (off the top of my head) that will make it sufficiently
less profitable is to ensure that the multiple streams behave exactly
in the manner of a single stream.  This would require the TCP retry
mechanism to track the steams together and punish additional streams
for each fault in the other streams.

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




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