Socket.io client keeps disconnecting and reconnecting at a fixed interval because of ping timeout

[valentin-at-edlio]

Recently I've updated my socket.io server and client to 4.6.1 and ever since then my client keeps disconnectiong and reconnecting at a fixed interval. The disconnection reason on the client is ping timeout...

It does not matter whether the tab is in the foreground or background.
I cannot reproduce this issue on localhost.

I still have a client that uses 2.2.0 and it does not reconnect at all and seems to be working correctly.

Left is 2.2.0, right is 4.6.1. They both connect to the same server.

And more importantly the 4.6.1 client receives the ping (2) and sends the pong (3) message to the server, but it does not seem to matter.

Socket.IO server version: 4.6.1

Server

    this.io = new Server(httpServer, {
      allowEIO3: true,
      serveClient: false
    });

Socket.IO client version: 4.6.1

Client

    this.socket = io(url, {
      transports: ['websocket'],
      reconnection: true,
      reconnectionAttempts: 50,
      reconnectionDelay: 5000,
      reconnectionDelayMax: 25000,
      auth: {
        token: *****
      }
    });

Expected behavior
I expect the 4.6.1 client not to reconnect at a fixed interval.

Platform:
I can reproduce with:

• Chrome Version 113.0.5672.127 (Official Build) (64-bit)
• Firefox 113.0.1 (64-bit)
• Microsoft Edge Version 113.0.1774.50 (Official build) (64-bit)

[darrachequesne]

Hi! Thanks for the details 👍

This "1.2 minute" delay is weird indeed. It does not seem related to the heartbeat mechanism, as pingInterval/pingTimeout values default to 25s/20s (your screenshot seems to agree with that).

Reference: https://socket.io/docs/v4/server-options/#pinginterval

I cannot reproduce this issue on localhost.

Could it be linked to the platform where your server is deployed? Does it happen if you regularly send some data from server to client (or vice versa)?

[valentin-at-edlio]

Could it be linked to the platform where your server is deployed?

Not sure since as I said an older client can connect just fine. Currently my server is running as an app service on Azure. I'll try to test it on a different platform...

Does it happen if you regularly send some data from server to client (or vice versa)?

Yes, it does. I tried spamming the server with an event to which it is supposed to respond with all online users. It worked right until the first ping-pong, then the server stopped answering.

I see that the new 4.x client receives a ping then sends a pong while the 2.x client sends the ping then receives the pong. I'm not sure if it matters, just pointing out.

I've tested different client versions and I can reproduce the issue with 3.1.3, but 2.5.0 works.

[selvaganes]

Hi! Thanks for the details 👍

This "1.2 minute" delay is weird indeed. It does not seem related to the heartbeat mechanism, as pingInterval/pingTimeout values default to 25s/20s (your screenshot seems to agree with that).

Reference: https://socket.io/docs/v4/server-options/#pinginterval

I cannot reproduce this issue on localhost.

Could it be linked to the platform where your server is deployed? Does it happen if you regularly send some data from server to client (or vice versa)?

[selvaganes]

After doing a bit more testing on different scenarios, I am adding a bit more information on the topic discussed here.

A) When I install up to version 4.4.1 using npm. I get the following message post install npm audit:-
npm audit report

socket.io-parser 4.0.4 - 4.2.2
Severity: critical
Insufficient validation when decoding a Socket.IO packet - GHSA-qm95-pgcg-qqfq
Insufficient validation when decoding a Socket.IO packet - GHSA-cqmj-92xf-r6r9
fix available via npm audit fix
node_modules/socket.io-client/node_modules/socket.io-parser
socket.io-client 1.0.0-pre - 1.0.1 || 4.3.0 - 4.4.1
Depends on vulnerable versions of socket.io-parser
node_modules/socket.io-client

2 critical severity vulnerabilities

To address all issues, run:
npm audit fix

If I were to run this unfixed without 'npm audit fix', everything runs fine on the event disconnect on the client
If I were to run 'npm audit fix' the disconnect event on the client with the reason 'parse error' is triggered and new socket sessions are created on the server side.

B) When I install Version 4.5.1. Get a clean audit report with no vulnerabilities. However, on the browser which uses the socket.io-client, the following error is thrown from the browser:-

[Error] ERROR – Error: invalid payload — index.js:215
Error: invalid payload — index.js:215decodeString — index.js:215add — index.js:118ondata — manager.js:192ondata(anonymous function) — index.mjs:136onPacket — socket.js:324onPacket(anonymous function) — index.mjs:136onPacket — transport.js:105onData — transport.js:97wrapFn — zone.js:769onInvokeTask — core.mjs:23899onInvokeTask — core.mjs:24197runTask — zone.js:178invokeTask — zone.js:490invokeTask — zone.js:1664globalCallback — zone.js:1695
handleError (vendor.js:71258)
next (vendor.js:87405)
next
next (vendor.js:41150)
_next (vendor.js:41119)
next (vendor.js:41092)
(anonymous function) (vendor.js:40929)
errorContext (vendor.js:44238)
next (vendor.js:40922)
emit (vendor.js:83398)
run (polyfills.js:7358)
onHandleError (vendor.js:86716)
runTask (polyfills.js:7406)
invokeTask (polyfills.js:7679)
invokeTask (polyfills.js:8830)
globalCallback (polyfills.js:8860)

The disconnect event on the client is not triggered. On the server side, the disconnect event that is displayed is "ping timeout"

C) On version 4.6.1, the audit report is clean with no vulnerabilities.
The disconnect event on the client with the reason 'parse error' is triggered.
The disconnect event on the server with the reason 'transport close' or 'transport error' is triggered as there seem to be many socket sessions for each new reconnect that was done.

The above scenario applies to both on localhost and remote servers.

Hope the above information helps more in finding the cause of this issue

[selvaganes]

D) On version 4.6.2, upgraded both server and client to the new version. Issue and symptoms are still the same.
The disconnect event on the client with the reason 'parse error' is triggered.
The disconnect event on the server with the reason 'transport close'

Additional Information.

When a request is sent, the client establishes a connection and performs the request. Then when another request is sent out, the disconnect happens, and a new connection is formed

The disconnect event is not fired on the client and server at the same time. While the disconnect with the reason 'parse error' is triggered immediately, there is no disconnect event on the server side. However, when the connection is terminated/disconnected intentionally, the server disconnect event is triggered multiple times with reason 'transport close' ( depending on how many requests were previously made ).

[yakirs57]

I have experienced the same issues. I had to revert back to the older version of socketio. If required I can also supply some logs and data.

[darrachequesne]

@selvaganes I was not able to reproduce the "parse error" issue, could you please provide a reproducible example by forking the example here please?

"parse error" would mean that the server has sent some invalid packet, which seems weird. Could you please check the packet in the devtools?

@yakirs57 same question, could you please provide some way to reproduce the issue?

@valentin-at-edlio so, if I understand correctly, server v4 + client v3/v4 does not work, but server v4 + client v2 does?

I see that the new 4.x client receives a ping then sends a pong while the 2.x client sends the ping then receives the pong. I'm not sure if it matters, just pointing out.

Yes, that's indeed the main difference between v2 and v3/v4:

• in v2, the client sends a PING and the server responds with a PONG
• in v3/v4, the server sends a PING and the client responds with a PONG

[selvaganes]

@darrachequesne @yakirs57 @valentin-at-edlio
The error can be seen clearly here on the tweaked version of your fork.

The test scenarios described in the README

These is a null value in the packets, but I think you will also be able to see directly for better understanding.

Hope this is helpful and if you have anything further do let me know.

[darrachequesne]

@selvaganes thanks a lot for taking the time to provide a reproducible test case ❤️

It seems there is an error in your example here: https://github.com/selvaganes/socket.io-fiddle-ouput/blob/e74a5909162bcc80e3f595ffe1832bf259f84f3d/server.js#L20

socket.on('request', (sneeze, callback ) => {
  console.log(`Request received from ${socket.id}: ${sneeze}`)
  socket.emit(callback(`Responded ${socket.id}: Bless you!!!`))
});

It should be either:

socket.on('request', (sneeze, callback ) => {
  console.log(`Request received from ${socket.id}: ${sneeze}`)
  callback(`Responded ${socket.id}: Bless you!!!`);
});

or

socket.on('request', (sneeze) => {
  console.log(`Request received from ${socket.id}: ${sneeze}`)
  socket.emit('response', `Responded ${socket.id}: Bless you!!!`);
});

In your example, socket.emit() is called with undefined (the return value of the callback()), which is now forbidden by the library (since socketio/socket.io-parser@3b78117) and cause the "parse error" disconnection.

[selvaganes]

Yes it works. Thank you very very very much :)

[valentin-at-edlio]

@valentin-at-edlio so, if I understand correctly, server v4 + client v3/v4 does not work, but server v4 + client v2 does?

@darrachequesne Yes, at least this is what I have experienced. I've upgraded my prod server to 4.6.1, but left all clients at 2.2.0 and everything seems to work well.