C++ socket server architecture

Question

I'm designing a TCP socket server for my real-time game and I've come to two approaches to it's architecture. Here they are:

1. We start two threads. One listens for new connections in an indefinite loop and adds new clients to an array. Second sequentially scans all client sockets from the array and reads data from them.

2. We start one thread, which listens for new connections in an indefinite loop and then starts new thread for each client which reads data just from one socket.

I've made some tests with about 100 clients and I couldn't see difference in performance of both architectures. So, I want to ask your opinion, which way is better. Thank you!

Answer 1

This all rather depends on how real-time your game actually is.

In the first approach, you are implementing the demultiplexing of events on all of the open sockets - and presumably using select() or poll() to block. Clearly, whilst you can only receive notification of an event whilst blocked and you effectively serialise processing of the each event if several are delivered when you unblock.

In the second approach, you have potential to process events in parallel (especially on a multiprocessor system) and also to prioritise connections using thread priority. However, this approach uses more memory, and scheduling threads is considerably more expensive than iterating over a list of events in the first approach.

The questions you need to ask yourself are:

• Do you actually need to process events in parallel? (are you going to serialise execution in processing anyway?)
• Is the amount of processing on each event significantly more than the cost of scheduling threads?
• Will memory consumption for thread stacks limit scalability?
• Are your real-time requirements really that stringent?