No packages sent after briefly going offline when using long polling

[Artur-]

When setting Chrome to offline, the long polling connection in the browser is disconnected as expected. When setting Chrome back to "no throttling", the long polling connection is re-established.

However, SocketIoClient.sendPacket no longer sends any messages because the first check fails

        if (mConnection.getReadyState() == ReadyState.OPEN) {

In this situation, mConnection.getReadyState() remains ReadyState.CLOSED

[trinopoty]

You can't reuse the connection once it gets closed. The connection needs to be reinitialized.

[Artur-]

I see, maybe I misunderstand the value that socket.io is offering. I though it offered an abstraction on top of the engine io connection so you could code the application without taking the occasional reconnects into account, no matter if the reconnect is because of how long polling works, because of a websocket connection timing out or the user briefly losing network connection.

If this is not the case, is there documentation / an example somewhere on how you can implement this kind of reliable layer on top of socket.io so that you will not lose pushed messages due to short reconnects?

[Artur-]

My understanding is based on https://socket.io/docs/v4/client-offline-behavior/#buffered-events

"By default, any event emitted while the Socket is not connected will be buffered until reconnection.

While useful in most cases (when the reconnection delay is short), it could result in a huge spike of events when the connection is restored."

[trinopoty]

While the protocol can tolerate occasional drops in network packets. If for some reason the client sends a disconnect message, the connection cannot be reused. The same is true if the connection drop persists beyond the ping timeout.
You can try adjusting the ping interval and timeout on the server. Also, check to see if the client is sending a disconnect request at any point.

[trinopoty]

On a side note, while the socket.io client supports automatic reconnection, the protocol does not guarantee retransmission of messages queued while the socket was disconnected. By "disconnected", I mean either the client sent a disconnect message or the interval exceeded the ping timeout.