[RFC] Reconnection

[darrachequesne]

Currently, a message that is broadcast while the client is disconnected is lost for that particular client.

Idea 💡 : handle the reconnection of that client, and send the messages that were broadcast during its disconnection (up to a given delay)

Suggested API

Here is how it could work:

Server

io.on("connection", (socket) => {
  // socket.reconnection = true;
  // socket.id, socket.rooms and socket.data are restored
});

Client

socket.on("connect", () => {
  // socket.reconnection = true;
});

socket.on("<event>", () => {
  // receive all events that were sent during the disconnection
});

Suggested implementation

How it could be implemented:

• persistent ID

  • the server sends a private session ID during the handshake (along with the id attribute that is sent currently, which I think we cannot reuse because it's public)
  • upon disconnection, the socket.rooms and socket.data are persisted somewhere
  • upon reconnection, the client sends this private session ID, which is then checked by the server

• messages history

  • the server includes an ID to each message that is broadcast (io.emit())
  • upon reconnection, the client send the ID of the last message that it has processed

Questions

1. Why should we include it in the core, and not as an extension?

It could be interesting to include it in the core because some adapters (like the one based on MongoDB) already store the messages temporarily, so in that case it is quite easy to implement.

Compatibility with existing adapters:

• MongoDB: ✔️
• PostgreSQL: almost
• Redis: no, but we could use Redis streams
• In-memory: no

2. Would this be a breaking change?

We only add a few fields (the private session ID in the CONNECT packet and the packet ID in the EVENT packets), so it might be backward compatible.

What do you think?

Update: this feature was implemented in version 4.6.0: https://socket.io/docs/v4/connection-state-recovery

[qiulang]

I like the reconnection idea. It doesn't just apply for broadcast but to one-on-one connection too.
This is a question I asked at SO in 2020 How do I let socket.io server re-emit message to a particular socket when that socket re-connect? and I came up with a home-made solution during that time.

Someone answered it yesterday suggesting using room to handle it, which brings me to this discussion to see if socket.io comes up with any new idea. And I saw this, what a coincidence!

[d3x0r]

I wouldn't count on messages previously sent to linger around in case someone reconnects... rather on connection I'd send the whole current state as if it was a new connection rather than a reconnection; which should include whatever change the missed message would have had.....
does seem more like a design philosophy you'd like to implement rather than anything someone else should provide.
There's certainly a lot of ways you can hold onto some amount of messages for some amount of time until the client reconnects; seems there's just as often as a 'hey I'm back, just send me the new info' vs 'reloaded because the user was impatient and need all info' happens that it's sort of redundant work to maintain both; I dunno maybe your current state is truly huge, but then pieces you have should be synced with indexdb locally, and then ask for new changes?

[darrachequesne]

For future readers:

This feature was implemented in version 4.6.0: https://socket.io/docs/v4/connection-state-recovery