Thread: Linux Network Programming (server architeture)

In the book Linux Networking Programming three methods are discussed for server architecture.
Multiplexing - a listen socket is created then using select on a set of socket discriptors a set with active sockets is returned. We then iterate through the set, if it is the listen socket we accept a child socket and add the child socket discriptor to the main watched set. If it is a childsocket we process the request for the childsocket. This is all sequential testing each socket discriptor in the active set and then processing.

In the process pool we use fork which creates a pool that each wait to accept child sockets on the listen socket.

The multithreaded is similar creating a pool of threads that accept clients each thread blocking until a connection occures.
(This method shares resources unlike the process method.)

It then makes a little comment about combing these methods but gives no example.

While both the thread pooling method seems efficient you have a bunch of dead threads waiting on client connections. Would it be better to use select on the listing socket and spawn a single thread when there is activity over pooling multiple threads?

Second assuming a child socket is created using accept. It seems to me their is no guarantee somthing is there to be read from the socket. So should I use multiplexing and add the new socket to the watch set the test the set for activity. Or can I assume there is somthing to be read if a client is connecting.

The gist of this thread is I am a little confused about combing these methods.

For a simple chat app preforking would not be good because new clients would not be visible to all processes unless I used specific resource sharing techniques across processes which I dont know who to do. If I had say 256 clients a thread pool may eat up all my resources, before the max clients connected. Multiplexing polls the socket discriptors for activity but if the thread handles a new connection and processes the request there is no further need for polling hence part of my confusion

There is another server architecture which is probably more popular than both of the ones you listed. This one is a multithreaded approach, but a new thread is only created once there is a new client connection in the main thread. The new thread can then handle the sending/receiving of data to/from the connected client. I personally like this approach since you can use blocking sockets without ever using select().

Would it be better to use select on the listing socket and spawn a single thread when there is activity over pooling multiple threads?

Yes, this is pretty much the approach that I outlined above. The only time it is useful to have multiple threads waiting on connections is if your application handles multiple connections per second. Even then its usefulness can be debated.

It seems to me their is no guarantee somthing is there to be read from the socket

That is true.

So should I use multiplexing and add the new socket to the watch set the test the set for activity. Or can I assume there is somthing to be read if a client is connecting.

You can't assume there is something to be read, this is entirely dependent on the protocol between the client and the server. Pretty much every protocol I can think of has the server send data first though.

Multiplexing polls the socket discriptors for activity but if the thread handles a new connection and processes the request there is no further need for polling hence part of my confusion

There is no need for socket polling and multithreading. Pick one method or the other

The only problem with creating a thread when you have a new connection is the expense of creating the thread. I'm not sure how expensive this is in Linux, but I expect it's more expensive than having a pool of idle threads waiting on a condition variable, and waking one of those when there's a new connection.

So I'd probably favour a machine and application-scaled thread pool and a condition variable as your basic "hand off new connection to a thread" mechanism.

I've heard of other functions like epoll() and others, though I don't program on Linux so I haven't used them..you could try google.

Thanks that clears up much of my cofusion. I still wonder which is more scalable for large client pools connections. Handling each connection with a newly created thread. Or creating the entire pool first.

It seems a good idea would be to keep track of the number of connections and after it gets near the max allocating anothe group of threads. Still this is not the single client per thread method and it negates the need to poll the listen socket.

Is there a way to poll a single socket (the listen socket) w/o select. Is that what epoll does. I'll google. Thanks for the replies.