Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Dec 1999 15:01:41 -0500 (EST)
From:      Chris Sedore <cmsedore@maxwell.syr.edu>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Kevin Day <toasty@dragondata.com>, "Ronald F. Guilmette" <rfg@monkeys.com>, hackers@FreeBSD.ORG
Subject:   Re: Practical limit for number of TCP connections?
Message-ID:  <Pine.BSF.4.05.9912191455490.72333-100000@qwerty.maxwell.syr.edu>
In-Reply-To: <Pine.BSF.4.21.9912181523530.12109-100000@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 18 Dec 1999, Alfred Perlstein wrote:

> On Sat, 18 Dec 1999, Kevin Day wrote:
> 
> > > The _clean_ way of doing it would be to write your multi-user server using
> > > threads, and to assign one thread to each connection.  If you can do that,
> > > then the logic in the program becomes quite simple.  Each thread just sits
> > > there, blocked on a call to read(), until something comes in, and then it
> > > just parses the command, does whatever it is supposed to do in response to
> > > that command, and then goes back to the read() again.
> > > 
> > > But as I understand it, there is not yet sufficient threads support in the
> > > FreeBSD kernel to make this work well/properly.  (I may perhaps be misinformed
> > > about that, but that's what I have been told anyway.)
> > 
> > I believe this is how ConferenceRoom works, so it seems ok, but I remember
> > the comments that FreeBSD was their least preferred platform because of
> > thread problems.
> 
> Using a thread per connection has always been a bogus way of programming,
> it's easy, but it doesn't work very well.

Ahem.  Well, that kind of depends on the threads implementation, how many
connections you're talking about, and likely some other factors too.  
I've got an NT box that handles about 1000 concurrent connections with
1000 (plus a few) threads doing the work.  Runs fine, performs very well.

I wouldn't argue that it is the most scalable solution to problems, but it
is easier, and scales proportionally to the quality of the threads
implementation.

-Chris



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?Pine.BSF.4.05.9912191455490.72333-100000>