I am currently creating a game in need of networking i.e. server and clients. I have basic experience with socket programming and am able to transfer data between two machines via UDP sockets using sdl_net. Now I would like to start building a game server and client for one of my current projects. Ive taken a look at https://gafferongames.com to help with packet compression and emulating a connection, however i am stumped from there on.

Because my game will be a real-time game, it constantly needs to be sending packets back and forth (perhaps at a set interval) to exchange data and check for timeouts. How do I structure my server? Should I have a thread constantly listening for clients packets and another broadcasting game states every time interval? Or should I stick to a single thread (If so how do I approach it)?

Simply put, I'm a little lost on how to properly make a efficient game server. Any help and explanation would be great!


1 Answer 1


A common architecture is to have:

  • one thread which listens to network messages from clients, parses them and collects the parsed results in a message queue.
  • At least one other thread which runs the game loop.

At one specific point in the game loop, the following happens:

  • The game loop locks the message queue through a thread synchronization like a mutex, semaphore or critical section. The network thread will now block while it tries to enqueue new messages.
  • The game loop processes all the network messages from the queue.
  • The game loop unlocks the message queue so the network thread can add more messages for the next update.
  • The game loop updates the world state
  • The game loop sends the results of its update to the clients

Processing network messages at one specific point in your game loop has the advantage that you avoid race conditions. If a network message can cause a gamestate change at pretty much any point of the game loop, then it might do so when you least expect it. This can cause bugs which are very difficult to reproduce and debug, because they only occur when things happen with very specific timing.

  • \$\begingroup\$ Thanks. I also have a few additional questions. First, is should the network listening thread continue to listen even though the message queue is blocked(discarding packets when being processed in update loop), thus always listening? Could this current design be viable in a single thread? From many examples I have seen they have put a while loop to receive packets inside the same function as the update loop. \$\endgroup\$
    – ADuckWhat
    Feb 6, 2020 at 20:33
  • \$\begingroup\$ @ADuckWhat That depends on the implementation of your network API. Some APIs have a very generous input buffer, so not accepting messages for a while won't be an issue because they will all be kept for later. But I also had to work with APIs which would just start to drop messages when you didn't poll them frequently enough. Some network APIs actually abstract the network thread away for you and only give you an interface to poll the message queue they provide to you. This design allows you to write your own code single-threaded. \$\endgroup\$
    – Philipp
    Feb 6, 2020 at 20:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .