Hacker News new | ask | show | jobs
by DiThi 3118 days ago
(Not OP but I had the same idea)

When a packet is lost in a TCP stream, it must be retransmitted, and until the client receives it, all further packets are stuck in limbo (received by the client, but cannot be seen). For this reason, most games use UDP instead, and are designed so some packet loss is acceptable (if I received where you are at frame N, it no longer matters if I receive where you were at frame N-1).

Minecraft uses TCP, that's why in very populated servers occasionally you can see the whole world freeze for a second.

In the browser we have UDP with WebRTC data, the problem is that not all browsers support it, it may not work in some places and for now it's more difficult to work with.

An easy compromise is to use several TCP connections, so if one packet is lost, instead of having N packets stuck for a moment, you have 1/N where N is the number of connections. And if important packets are sent through all channels, the chance that they arrive too late is much lower.

1 comments

Do both websocket connections send the same data, or do you split your data logically between two channels (movement data vs state data)
I interleave information that becomes redundant (like the position of players, I can handle losing every other packet for a while, interpolating/predicting missing info) but send important data in all channels (like when a rocket is fired, it's just one event that must be seen).

Again, I'm not OP but I did similar things and explained what probably happens with this game.