Currently I'm working on a MMO game which players can join and exit game whenever they want. I have a connection manager server (CMS) written in golang using socket io library. World connects to CMS and clients connect to CMS and talk to world and world update clients with snapshots of game state. For testing I wrote a client that connects to CMS and act as a player for testing how many clients can my CMS handle. I reach around 80 clients per one core vcpu and 1 gig ram and that's acceptable for my game and resources. I released the game but in real life when there is around 5 or 6 real players and one player with bad network connection joins game it massively take effect the another players game experience. Packets don't receive to another clients or delayed heavily! I believe it's because socket io uses tcp and when a bad network client joins it should send messages many times for client received it completely. How should I overcome this? I know I should used udp for my game but it's too late and I released my game in play store and it got around 700 installs. Is there anyway I can put a time to live like attribute to messages that if client don't received them at a certain time dropped them? Any idea whould be helpful.

  • \$\begingroup\$ Obligatory cautionary comment: gamedev.net/blogs/entry/… \$\endgroup\$
    – Bálint
    Commented Feb 22, 2019 at 12:22
  • \$\begingroup\$ Very good blog post, But i'm developing a small io game (like Agar.io and slither.io) and i think it can develop by individual team. \$\endgroup\$ Commented Feb 25, 2019 at 15:40

1 Answer 1


Packets don't receive to another clients or delayed heavily!

Since you didn't provide any definitive information (like your servers update loop or some pseudo-code) i have guess: Are you (or Socket.io) doing blocking writes to the TCP stream somewhere? Are you sending world updates regardless of whether the client can process them fast enough or not? Are you even checking if your client has received/processed your updates? Sounds like your server isn't serving the clients asynchronously, either per design or accident, which would explain why a bad client can pull down the whole server.

If you are really running on a half decent VPS (which usually have 100 to 1000 Mbit/s uplink) the network speed would be more than sufficient to handle hundreds to thousands of clients. The network speed surely isn't your root problem, you're probably not even coming close to saturating your VPSes connection.

It's how your server handles the data distribution that's causing trouble.

Any idea whould be helpful.

Stop serving clients when their connection speed drops, I'm not talking about kicking them off, just stop sending them world updates when they are not able to process them. Continue sending them updates once the situation improves!

If you just keep pushing updates to a client that has connection problems you will pile up heaps of data in the send-buffer of your server. This will completely saturate the clients connection once it's speed improves. It might even block your server once you pile up enough data, that depends on how socket.io handles this internally.

Remember that when using TCP or other reliable stream-like protocols nothing will be lost, which in turn can lead to data accumulating. This can cause additional latency and bandwidth spikes if not handled well. It will lead to unrecoverable situations if your server does not react to this.

  • \$\begingroup\$ Thanks for your detailed answer. I make it accepted. but i have another question from "If you just keep pushing updates to a client that has connection problems you will pile up heaps of data in the send-buffer of your server." part of your answer, i asked in github repo of my socket.io library that how can i access this send-buffer of my server and they tell me it's somewhere in kernel and i can't access it in my socket.io library. how can i see the messages and size of this send-buffer in my server? \$\endgroup\$ Commented Feb 25, 2019 at 15:44
  • \$\begingroup\$ It would be great to be able to have this kind of buffer feedback, i don't know of any way to get this value for individual sockets though. You'll probably have to make the client send back the id/timestamp/whatever of the newest packet he received from the server. That way the server can judge how far the client is behind and throttle accordingly. \$\endgroup\$
    – VaTTeRGeR
    Commented Feb 25, 2019 at 16:30

You must log in to answer this question.

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