As my game is purely multiplayer, online performance is important.

Should I run two threads for each player/connection? (One for input and one for output) or should I run one thread for all player input and one thread for all player output?

What is the pros and cons, and how do I deal with high ping players in the second method?

  • 1
    \$\begingroup\$ How about one thread that does asynchronous network reads and writes? MMORPG style server processes are all single threaded but are made to be able to communicate with other processes. This let's you spin up n threads per box, as well as n boxes. If you are worried about processing time, you could thread your work (like path finding or collision detection or animation). Either truly asynchronously or in a "fork join" method when you have a lot of work to do that you can split up among threads. \$\endgroup\$
    – Alan Wolfe
    Commented May 29, 2015 at 21:08

1 Answer 1


As a general guiding principle, avoid "One Thread Per User" designs, especially for networking. Managing thread interactions is a known hard problem, and having an uncertain number of threads drives that complexity.

A thread per major functional category is more manageable, and scales nicer with actual multiple cores. (@Alan Wolfe's comment alludes to this.) A thread for physics, a thread for management console, a thread for networking...

deal with high ping players

The same way as with fast-ping players: you never (ever!!) block on network access. What you want is known as "asynchronous i/o". It can take various forms, such as event callbacks to your code from the i/o system (like JavaScript), or look like one master polling loop (like *NIX select() call).

(I confess, I've only done very simple client-side Java networking, not recently, so I'm not fluent in server side asynch for Java. But it looks like java.nio.channels.AsynchronousXxx are the relevant classes.)

Now, behind the scenes, the i/o system may be using threads... but they're trained professionals, that is, it's mission critical and they've worked the bugs out so we don't have to.


You must log in to answer this question.

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