-2
\$\begingroup\$

So if the Thread pool handles 10 players out of 100 per second, this could make a delay that will be no good for real-time games, so as I see it that MultiThreaded will be better, thus it will handle all the 100 players at the same time, but I wonder if there are other options for this?

\$\endgroup\$

closed as unclear what you're asking by Anko, Josh Jun 12 '15 at 17:43

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Your measurements seem a bit invented, but if you do not have enough power to drive a sufficiently sized thread pool, you will not have enough power to drive individual blocking threads as they are similiar in cost. Invest in more iron. \$\endgroup\$ – Lars Viklund Jun 11 '15 at 15:03
-1
\$\begingroup\$

When you make an online game where multiple connections to clients will be made, you want to read from them as fast and soon as possible. Inducing lag on the server side is a bad idea, especially for packets that need to be treated fast.

The best way to handle these connections is to have one thread running for each client. Most networking engines will block when reading or waiting for data, so that is why you need to thread all reading done from the sockets (assuming you use sockets) or any other connection type.

To write data to the clients, however, you can use a single thread, or reuse the threads you have set up for reading if you want. Flushing data out on a connection is blocking in most of the cases, but it will not block for a long time, so you can afford to run it on the main thread. Do send big data chuncks (like files) on a seperate thread like you would do when reading the said file.

In summary:

Thread Pool

  • Will induce lag for receiving packets, and will sometimes even miss some.
  • Is, however, more performant than having one thread per client.
  • In the end, Thread Pools are a greedy optimization that has too much downside for the advantages it gives.

One thread per client

  • Will not miss any packet, and can be bound to events better.
  • This is the safe way to go, and probably the best in all cases.
\$\endgroup\$
0
\$\begingroup\$

Thread handling is always a pain and the source of countless obscure and irreproducible bugs.

I would recommend you to leave the thread management of the receiver threads to the operating system and use Non-Blocking IO with Selectors and SocketChannels. This allows you to handle hundreds or even thousands of sockets with a single thread.

A common NIO handler is a loop which always gives you a set of channels which are ready to perform a specific operation. On most common operating systems it interfaces directly with low-level functionalities of the operating system which means that it is much more efficient at this than your own implementation with one socket per client could ever be.

In my last project I had one thread with NIO to handle the network IO, but that thread was just receiving the network messages, parse them, and then dispatch them to event queues of other threads (one for each active map chunk) which did the heavy lifting regarding calculating game mechanics.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.