I'm designing a TCP socket server for my real-time game and I've come to two approaches to its architecture. Here they are:
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.
We start one thread, which listens for new connections in an indefinite loop, and then start a 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 the difference in the performance of both architectures. So, I want to ask your opinion, which way is better. Thank you!
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: