Server multi-threading, a must for Protocol ? and more

Suppose a application level protocol is implemented via UDP. Client timeout is required, thus server need to keep state of each client it talks to.

Also suppose select is used.

1. Is it always the best to implement multi-threading server? I figure a link-list will do the same, where server timeout time=Earliest Timeout of a client- CurrentTime . A link-list will have the same function as keeping client's states, while avoiding the overhead of cr开发者_开发技巧eating new threads(though introducing some complexity for server to maintain client-specific timeout).

2. If multi-threading is chosen, then onward, is it the best to invoke new socket for new client? This will introduce system resource overhead. But I figure the default server socket (bind with server well-known port) will do the same since it got buffer (well..maybe not long enough for scalable num of clients..)

Thanks!

In my experience, threading makes it very easy for your code to look logical and clean, when horrible synchronization issues are lurking, waiting for some events to occur in just the right sequence that the application blows up. Threading is a very useful tool - you need to think with threads if your application is going to be able to take full advantage of your CPU(s), and learning to work with threads is a step towards learning to leverage distributed processing (at least, I think so).

My preference is to write applications using asynchronous callbacks, instead of blocking calls, and explicitly direct which thread I want to use for handling the callback. This has the following advantages:

• It makes the state variable interactions much more controllable, therefore predictable, which means the threading is more robust.
• If done right, it can take the best advantage of the number of processors your CPU has.
• It allows you to directly control the priority you want to give to certain functions - if this function is high-priority, you dispatch it to a high-priority thread, then when it completes, it sends the results back to the low priority caller via a continuation in the caller's thread. Or to another thread - no reason to limit that.
• It's often possible to port to non-threaded environments. Maybe not important for most, but sometimes important for me.

I'm not going to suggest anything new that isn't in the answer by Aidan Cully, however, take a look at the theory behind Apache's Multi Processing Modules: http://www.linuxquestions.org/linux/answers/Networking/Multi_Processing_Module_in_Apache

In essence, the server is split into multiple modules and threads/processes are created to manage connections, depending on need and configuration options - it sounds like the balance described in Aidan's answer although the Apache implementation may differ slightly.

Linked-Lists will not scale.

Using linked lists on the server-side to check the clients one-by-one and address their needs is all well and good for 5 to 10 clients. But what happens when you have 100? 1000? What happens if one clients request takes a very long time to handle?

Threads don't just provide a way of maintaing state for individual clients. They also provide a way of simultaneously "distributing the server resources" across all clients. It's as if each client has a dedicated server to itself, there is (almost) no queue: the client wants something, it asks the server, the server replies. It's instantaneous.

Plus, you could be wasting valuable resources with your linked list approach. What if all the clients but one want nothing? You'll be cycling repeatedly over a hundred clients, doing nothing but wasting CPU cycles, until you come across the one that does require the server's attention.

Multi-threading is definitely not a must as you have already come up with an alternative. We can't really use absolutes like always or never as each case has unique requirements and constraints.

Yes, adding a new thread/socket for each connection will consume more resources. It sounds like you need to get a good definition of how many connections you will need. Then you can determine if you will have sufficient resources or not.

If the resources constraints are not a concern, I would choose the simpler solution. Is it easier to use the tools you already have (i.e. well tested functions to handle threads and sockets) as opposed to writing a new body of functionality (the linked list suggestion)? What about code maintenance? If another programmer works on this project in the future, would it would be easier for them to understand an implementation with standard operating system calls they are already familiar with or a linked list?