Can Socket.io emits arrive out of order? What if volatile?

Question

I've been looking around for a definitive answer to this but I seem to keep finding contradictory answers (ex this and this).

Basically, if I

socket.emit('game_update', {n: 1});

from a node.js server and then, 20 ms later,

socket.emit('game_update', {n: 2});

from the same server, is there any way that the n:2 message arrives before the n:1 message? In other words, does the n:1 message "block" the receiving of the n:2 message if the n:1 message somehow got lost on the way?

What if they were volatile emits? My understanding is that the n:1 message wouldn't block the n:2 message -- if the n:1 message got dropped, the n:2 message would still be received whenever it arrived.

Background: I'm building a node.js game server and want to better understand how my game updates are traveling. I'm using volatile emit right now and I would like to increase the server's tick rate, but I want to make sure that independent game updates wouldn't block each other. I would rather the client receive an update every 30 ms with a few dropped updates scattered here and there than have the client receive an update, receive nothing for 200 ms, and then receive 6 more updates all at once.

Answer 1

Disclaimer: I'm not completely familiar with the internals of socket.io.

is there any way that the n:2 message arrives before the n:1 message?

It depends on the transport that you're using. For the polling transport, I think it's fair to say that it's perfectly possible for messages to arrive out-of-order, because each message can arrive over a different connection.

With the websocket transport, which maintains a persistent connection, the message order is reasonably guaranteed.

What if they were volatile emits?

With volatile emits, all bets are off, it's fire-and-forget. I think that in normal situations, the server will wait (and queue up messages) for a client to be ready to receive messages, unless those messages are volatile, in which case the server will just drop them.

From what you're saying, I think that volatile emits are what you want, although once a websocket connection has been established I don't think you'll see the described scenario ("receive an update, receive nothing for 200 ms, and then receive 6 more updates all at once") is likely to happen. Perhaps only when the connection gets lost and is re-established.