socket.io-client
socket.io-client copied to clipboard
Idea: reset ping timeout timer on any incoming packet
In my testing I found that latest socket.io client can disconnect with ping timeout even if it is spammed with incoming packets (a lot of network activity).
I found that resetPingTimeout is called only on ping requests (and on handshake):
https://github.com/socketio/socket.io-client/blob/0a7efc82170dae19e2a20ff513045de4c4ac2987/dist/socket.io.js#L2895-L2900
Server side socket.io library also resets its timer on any data:
// Reset ping timeout on any packet, incoming data is a good sign of
// other side's liveness
this.resetPingTimeout(
this.server.opts.pingInterval + this.server.opts.pingTimeout
);
https://github.com/socketio/engine.io/blob/ebb36f298d9ac2c6a5f2582ac0101dc0aa5a88f5/lib/socket.js#L91-L95
In my project I added onAny listener to client's socket with manual reset:
socket.io.engine.resetPingTimeout(
socket.io.engine.pingTimeout +
socket.io.engine.pingInterval
);
This makes client be still able to recognize disconnect when there are truly no ping packets, but if there are any network activity, it resets its ping timeout timer. This seems to work well for me, but why not include such logic in the socket.io client library itself?
That's an interesting idea! I guess we could also reset it for outgoing packets too, so the timeouts are kept more or less in sync. What do you think?
That's an interesting idea! I guess we could also reset it for outgoing packets too, so the timeouts are kept more or less in sync. What do you think?
As far as I understand outgoing packets are not a very reliable sign of connectivity.
I can call emit, say, a hounded times but the connection can actually be already lost on the other end. Because sometimes the loss of the connection can not be detected by any means except by ping timeout.
For example, a firewall can just start to drop all the packets without closing the connection.
For future readers:
This was done in https://github.com/socketio/engine.io-client/commit/ed34a45a0780b944a387c3a685d4f3af758cc2fa, included in [email protected] and [email protected].