RE: [Algorithms] Concurrent server.

[Brian S. <bs...@mi...>]

Your last solution is the way to go.  2000 threads will cause your
server to spend all its time context switching.  All the webserver
writers started with the one-thread-per-client model until they realized
it doesn't scale at all (I think Apache figured this out first and beat
the crap out of everyone else in the benchmarks for a while :).  Now
they use thread pools (google that for more info).

Don't know if you're targeting Win32 or Linux, but on Win32 select() is
not the most efficient way to wait for multiple sockets; use completion
ports instead.

--brian

-----Original Message-----
From: Leigh McRae [mailto:lei...@co...]=20
Sent: Tuesday, April 23, 2002 8:14 PM
To: gda...@li...
Subject: [Algorithms] Concurrent server.


 Hey people,

  I have looked into writting a concurrent server that would support
around 2000 UDP clients.  I have read some methods that use a separate
thread and socket per client but I tend to think 2000 threads could get
rough. =20

  Is it possible to run one thread and one socket (same port)?  This
thread would route/ID the packets using the address from recFrom().  I
was wondering if this socket could get over run and packets get lost.
Does a socket have a huge buffer/backlog that would make this not a
problem?  Maybe having more than one socket helps with this problem by
having a buffer per socket?

  The other method I can think of is using one thread but a separate
socket (OS assigned port) per client.  Then use select to manage which
socket gets recFrom() called on it.  The problem with this method is
that the OS has a limited number of handles it can monitor.  Maybe this
could extend the multi-threaded version by having a thread handle a
bunch of sockets instead of one?  Something like 2000 connections / 64
sockets per thread =3D about 30 threads?

Leigh McRae