Sockets application with 200 clients

[Guest]

I am developing a network server application that will connect to around 200
clients. The client software is already developed so I have to work within
this constraint.

The server listens for connections from clients and establishes a socket
connection. The socket remains active until either the server or client is
shutdown.

The clients send data to the server when they have new data to send or when
a status request has been made by the server.

Most examples I have seen close the socket after the message is received or
the response is sent. How do I handle the situation where I have to keep the
sockets open and listen for more messages?

There are a couple of approaches I but I'm not sure which,if either, is the
best.

1. Use the Async sockets methods (BeginRead etc...) At the end of each
message I start a new BeginRead to wait for the next message. The problem I
see with this method is that it would require a thread for each client. The
upper limit for clients is around 200. Is it reasonable to have 200 threads?

2. Poll the sockets to see which have data available for reading using
..Available or .Select., then use the Async methods to read the data.

Any help is greatly appreciated.

 

[NuTcAsE]

Looking at your requirement i would suggest not having a threaded
approach. 200 threads and 200 open sockets is a disaster waiting to
happen. Just for clarity, do you mean that when a client connects to
your server only once a connection is opened between them and then from
then on they communicate through that socket only?

 

[Guest]

Yes, that is correct. Once a socket connection is established all
communication from then on is done using this socket.

 

[William Stacey [MVP]]

200 sockets and 200 threads is no problem. I would not go above 800 or so
however.

 

[David Browne]

200 sockets and 200 threads is no problem. I would not go above 800 or so
however.

Second that. Think SQL Server. SQL Server uses one thread and one socket
per client, and runs with several hundred connections just fine.

To handle many thousands of connections (Think IIS), then you need to share
threads.

David

 

[Parahat Melayev]

Consider using Thread Pools
that
Threads already running and waiting for job to do.
Glance to queue subject will be helpful also...

 

[Michael E. Pouliot]

Second that. Think SQL Server. SQL Server uses one thread and one socket
per client, and runs with several hundred connections just fine.

To handle many thousands of connections (Think IIS), then you need to share
threads.

David

I don't think this is true. SQL Server may use one socket per client, but
there is not necessarily a one-to-one relationship between client
connections and work threads. SQL Server uses a worker thread pool to
service client requests.

For a high volume, server side application, I've always used I/O Completion
Ports in C++. I know there is an I/O Completion port implementation in
..NET, but I have no experience using it.

I would always avoid a "one thread/connection" design. A typical CPU can
only run one thread of execution at a time. Thus, having hundreds of active
threads provides no performance benefit. If the threads are usually idle,
then the model is workable, although with I/O Completion ports, context
switching is minimized. I know that IIS 4.0 was built around I/O Completion
ports, and it wouldn't surprise me if SQL Server 2000 and IIS 6.0 also
managed worker threads using the same mechanism.

MP

 

[David Browne]

I don't think this is true. SQL Server may use one socket per client, but
there is not necessarily a one-to-one relationship between client
connections and work threads. SQL Server uses a worker thread pool to
service client requests.

That was a bit of a lie, sure. Oracle does, though. But the point is, up
to a few hundred concurrent clients the thread-per-client approach will work
just fine, especially if the threads aren't very busy. Other designs are
better, but at the cost of being harder to code and maintain.

David