0
\$\begingroup\$

My game is based on a client / server architecture where client only sends input and receives server output.

Server has to keep track of the game, updating the world etc. But also listen to clients and their input. The server accepts input for 100ms and then processes all the input,sending the result (the output) back.

What would be the most optimal in terms of performance. Have two processes, one for the game and one for listening to clients for input and sending output back. Or go full multi-threading.

I read on how to communicate between processes and it didn't seem very optimal (Sockets, RMI, file sharing).

\$\endgroup\$
  • \$\begingroup\$ This is too broad a question to answer fully, but multi threading is the way to go. A socket listener should be on it's own thread, and should send data to the server on yet another thread. Network delays should not affect client performance in any way. \$\endgroup\$ – Ian Young Nov 28 '17 at 13:15
  • \$\begingroup\$ Currently server listens on own thread and fires a new thread when it receives a connection on the socket. But besides that I have a very intensive task for my game, should I run it simply as another thread or process since its heavy? How can I make my question less broad? Maybe ask when to start using multi-processing instead of another thread? Can't find a proper answer to my use case on the net. \$\endgroup\$ – Krijn van der Burg Nov 28 '17 at 13:22
  • \$\begingroup\$ I would recommend googling network multiplayer best practices, or something similar. You are basically asking how to do network multiplayer, which there is no easy answer for. This is a whole field on it's own, so I would recommend putting in some more study into the field, and asking specific questions later. These questions will pop up the more you read. Try to refrain from questions that will illicit opinions. Keep the questions concise, and to the point. \$\endgroup\$ – Ian Young Nov 28 '17 at 13:27
  • \$\begingroup\$ I'm not asking how to do game networking, i've got that figured out. Im asking what performance wise is the best choice. Using threads within same application or use processes that need explicit communication between them. \$\endgroup\$ – Krijn van der Burg Nov 28 '17 at 13:35
  • \$\begingroup\$ Inter process communication should be avoided where possible, as the behaviour (changing memory owned by another executable), can trigger anti malware programs, and is considered insecure. \$\endgroup\$ – Ian Young Nov 28 '17 at 14:19
1
\$\begingroup\$

First of all, you should see what your platform offers you. Most networking systems will offer some form of non-blocking socket API where the nasty multi-threading is left to the operating system. All you have to do is poll the sockets at one point of your game loop to see if they have received any data. This is really convenient for you, because it prevents a lot of headache resulting from debugging multithreading bugs.

When you can't or don't want to use these APIs (you should!), then you will have to use blocking sockets. In that case you will have to create two threads per client, one for sending data and one for receiving it. The receiving threads should write their results to thread-safe data structures which are then polled by the main game thread each tick. Do not let the receive-threads manipulate the gamestate directly. Manipulating data by multiple threads is a recipe for disaster, because you never know when they are going to do that. Expect weird bugs which only appear very occasionally and are impossible to reproduce, because they depend on rarely occurring microsecond timing conditions.

You might also have to use the "thread-safe receive buffers" in some APIs which handle network messages with callback functions. Check the documentation to verify that these callbacks happen from their own threads (as opposed to a specific point in your game loop which you can specify).

Regarding your question of threads vs. processes: A process can do everything a thread can do, but is more expensive to create and maintain and interprocess communication is more cumbersome than communicating between threads which can simply pass object references to each other. IF you want to use multithreading, use one process with multiple threads. Multiple processes only make sense if you either want to distribute them over multiple servers (which can be very useful to ensure future scalability of MMOs) or when these processes are optional components people might or might not need (like a specialized reverse proxy server).

\$\endgroup\$
  • \$\begingroup\$ Good point about the system platform but im developing in java for all OS systems, not a specific one. Is what you suggest by using the system API's still viable / possible then? \$\endgroup\$ – Krijn van der Burg Nov 28 '17 at 14:08
  • \$\begingroup\$ @KrijnvanderBurg When you are using Java, then you should use the New-IO API. It's a great API for handling a large number of clients without having to use multithreading. \$\endgroup\$ – Philipp Nov 28 '17 at 14:12
  • \$\begingroup\$ @KrijnvanderBurg By the way, you might want to tag your questions with the technologies you are using. Best practices vary a lot depending on your framework. \$\endgroup\$ – Philipp Nov 28 '17 at 14:13
  • \$\begingroup\$ Good point and thanks for the answer, this helped me greatly to get further! \$\endgroup\$ – Krijn van der Burg Nov 28 '17 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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