1
\$\begingroup\$

I was developing an game. I using single threaded nodejs(socket.io) server. It is good for simple games or games like basic 3d world? Usually game will have 10-20 players(clients).

Also is single threaded server can handle multiple clients same time?

like player 1 walks player 2 jumps same time.

\$\endgroup\$
2
\$\begingroup\$

There is nothing good or bad about using NodeJS.

I have experience with multiple relatively heavy loaded projects (2-500 users on a 1 CPU machine) using nothing but NodeJS and Web sockets. No problems with performance. Games were not very complicated - mostly moving units on a 2D plane, units can shoot missiles or do melee attacks.

I'd recommend one of these packages: wse or vanilla ws.

NodeJS is actually not that slow in compare with c++ or g++.

Talking about performance - I'd recommend avoiding socket.io - is a very comfortable and simple library, but it works much slower. But it still not a problem for quick prototyping or a small number of connections (2-30 is small here).

I hope this answer is subjective enough to match the subjectivity of the subject.

P.S.: I'm currently working on a thing capable to handle 1000+ connections per machine. With no fear.

\$\endgroup\$
  • \$\begingroup\$ That's very impressive, I would not have expected that from JavaScript. Is that library you're using written in a compiled language? And what hardware is the server program running on? \$\endgroup\$ – AnnoyinC Nov 26 '20 at 13:49
  • \$\begingroup\$ @AnnoyinC ws has optional modules for performance boost - npmjs.com/package/ws#opt-in-for-performance-and-spec-compliance wse is a simple wrapper around ws to make some boring things easier. I used 1 or 2 CPU machines on DigitalOcean m.do.co/c/72cfd6567301 If you're not using docker or some other extra-layers - 1000 connections are actually not that much. And again - NodeJS is optimized (see v8 performance) - I'll add a link to my answer so you can see actual numbers. \$\endgroup\$ – Vladimir Ishenko Nov 26 '20 at 13:52
2
\$\begingroup\$

Usually you would have multiple threads in the case of TCP, each for one client connection, and a thread for gamestate/logic. In the case of UDP you have one listening/sending thread and one game state/logic thread.

TCP:

Anything comes in from a client you put it in a shared queue. For instance, you may have a seperate queue for jumps, for shooting, etc. Any game event happens you broadcast it across the clients.

Anyway, using TCP is a pretty bad idea anyway (for the game itself, for a chat it's good). You want to get packets out as fast as possible, and not wait for stuck packets that may take seconds to clear (which is why you have to use seperate threads, otherwise one bad player connection can throttle everything).

UDP:

You might want to keep track of the order of packets, if that is important to you. Also include a little header in each packet of what packets were last received, so you know if you have packet loss and need to resend anything. Here's some links that explain in more detail with code: https://www.gafferongames.com/post/virtual_connection_over_udp/ https://www.gafferongames.com/post/reliability_ordering_and_congestion_avoidance_over_udp/

Conclusion

As you can tell, both TCP and UDP have drawbacks and strongpoints.

TCP: very reliable, but slow, blocks a thread. Good for web servers, chats, user account login, anything that does not require millisecond speeds, but does require reliability.

UDP: lightning fast, non-blocking, unreliable. Used for things that just need very fast speed, use your own programming or a library to make it reliable.

Luckily since you are using node, somebody else has probably figured it out, sadly I'm not familiar with the node ecosystem.

Also, I'm not sure if it still applies on modern routers and modems, but it's often claimed that using both TCP and UDP on the same port can lead to connection problems. So I recommend you use different ports for your chat (TCP) (if you have a chat) and your game (UDP). It doesn't hurt either way.

\$\endgroup\$
  • \$\begingroup\$ One thread per client, doesn't it create synchronization issues? \$\endgroup\$ – Vaillancourt Nov 26 '20 at 15:21
  • 1
    \$\begingroup\$ @Vaillancourt Not really. Anything comes in from a client you put it in a shared queue. For instance, you may have a seperate queue for jumps, for shooting, etc. Any game event happens it gets broadcast across events. Anyway, using TCP is a pretty bad idea anyway (for the game). You want to get packets out as fast as possible, and not wait for stuck packets that may take seconds to clear (which is why you have to use seperate threads, otherwise one connection can throttle everything). \$\endgroup\$ – AnnoyinC Nov 26 '20 at 15:48

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.