On Wed, Feb 19, 2003 at 03:26:24PM -0500, Greg A. Woods wrote:
> First off note the original requirements you outlined do not justify
> stopping this kind of usage.

It's my server, and I get to decide how people connect to it--I really
need no justification. Which is why my reasons are actually quite
unimportant.

> Secondly note that IP# != person.

While true in general, not true in my case. I have server logs and know 
my user base. The majority of connections are from obviously 
single-user machines... From your postings to the lists, I gather that
you're an old-timer--I know multiuser timeshare type systems were all 
there was back in the day, but today, the vast majority of systems on 
the internet are single-user machines.

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

Only marginally better throughput--a percent or two improvement isn't
significant to me. As a test, I downloaded a 16 meg file with one
connection in 1:47. With 2 simultaneous connections, it took 1:41;
and with 3, 1:41. Yay. This is to a machine with an OC3 (and more)
to the rest of the net, so there's no bottleneck at that end. And
multiple connections has a huge adverse effect on users who only have 
one connection open. Which is _the_ reason I like to limit the number 
of connections/IP... you haven't addressed that issue at all. Better
throughput for one person at the expense of others is bad.

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

Right--I don't care how long people stay connected, and they can use
as much of my bandwidth as they want _as long as they're fair to other
users_. To reiterate, I want 5 people to each get 1/5th of the bandwidth.
I don't want one person to get 6/10ths of the bandwidth and the other 4
to get 1/10th each. It's all about being fair... if people don't want
to be fair out of the goodness of their hearts, well I'm gonna force
them to be fair, at least when it comes to my ftp server.

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

I _am_ running a ftpd that can limit by IP, and empirical evidence shows
that I _have_ solved the problem. I think your understanding of the
problem is flawed.

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

They make sense to me. Assume 1 IP = 1 user. Requirement: n users get
my bandwidth split "evenly," for some reasonable definition of "evenly."

But none of this has anything to do with the original question, which
was: Is it possible for NetBSD's ftpd to limit the number of simultaneous
connections from each IP. And it looks like as far as anyone can tell,
the answer is no.
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++