Subject: Re: FTPD: disallowing concurrent connections from same IP
To: Dave Huang <khym@azeotrope.org>
From: Greg A. Woods <woods@weird.com>
List: netbsd-users
Date: 02/19/2003 15:26:24
[ On Wednesday, February 19, 2003 at 02:00:08 (-0600), Dave Huang wrote: ]
> Subject: Re: FTPD: disallowing concurrent connections from same IP
>
> On Wed, Feb 19, 2003 at 02:19:31AM -0500, Greg A. Woods wrote:
> > 
> > Why do you want to do that exactly?  What problem are you trying to solve?
> 
> Is it important? I was just curious about how to get NetBSD's ftpd to
> do it. The machine where I'd like something like that is running Windows,
> so NetBSD's ftpd isn't gonna help in any case.

Yes, it's very important because just as I feared it's not a real
problem, or at least not one derived from your stated requirements.

> But an example situation where it'd be useful is to keep people from
> using "download accelerators" that open 7 or more simultaneous 
> connections and use "REST" to download chunks of the same file.

First off note the original requirements you outlined do not justify
stopping this kind of usage.

Secondly note that IP# != person.

Thirdly note that it's almost always easier to get better throughput
with multiple TCP connections.  So, usually one person grabbing one file
will be done sooner if they download it as a bunch of simultaneous
connections and that means they'll make the most effective use of the
resources you've made available and they'll be out of the way sooner and
make room for the next guy.  Obviously there are lots of border cases
and other things that make this a little less black & white, but in
general it applies.

If I remember correctly you've already stated that you don't care how
much traffic is consumed (the size of the pipe is the limit) and you
haven't imposed any other restrictions on the total number of
connections nor on the total usage by any given connection, and it seems
we're talking about anonymous clients.

I.e. you are not solving the problem you think you have, and worse the
problem you think you have isn't real -- it's not actually derived from
the requirements you stated.

Perhaps you can restate your requirements in some way that makes sense?

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>