Refacto icon indicating copy to clipboard operation
Refacto copied to clipboard

Auto reconnect WebSockets on close

Open davidje13 opened this issue 6 years ago • 2 comments

Close events are currently detected, but ignored (except for cancelling keepalive pings)

The client should attempt to automatically reconnect if the connection is lost unintentionally. This should use retry logic with an increasing delay to avoid self-DDoS.

If connection is lost for several seconds without reconnecting, a non-intrusive message should be displayed to the user.

davidje13 avatar Sep 08 '19 17:09 davidje13

To prevent missed or duplicated messages after reconnection, the server will need to keep track of which messages it has already handled;

  • on first connection, a client should request a UUID from the server
  • server should generate and return this UUID
  • client stores UUID locally (in-memory or in session storage)
  • messages sent by client include incrementing ID (already the case? I think this is used for matching the reflected messages)
  • server keeps track of highest ID handled for each client connection (stored as part of the main data, as a map of UUID -> counter, but not sent to any clients), and ignores any messages with ID lower than the current recorded value for that client UUID
  • on reconnection, client sends stored UUID instead of requesting new UUID
  • server associates new connection with the same UUID

Client UUIDs are known only to the server and the client, not other clients. It may also be necessary to limit the maximum number of UUIDs tracked by the server (perhaps including a timestamp in each entry and removing the oldest to maintain a maximum count, or more simply by keeping an ordered list in most-recently-used order)

davidje13 avatar Jun 02 '22 19:06 davidje13

For simplicity, my preferred approach here has changed:

  • update Refacto's actions to be idempotent - item creation and voting are currently the only non-idempotent actions:
    • creation can be changed with the new abilities of json-immutability-helper
    • voting could be made idempotent by adding UUIDs to a Set to vote, but this seems like overkill - voting can probably remain non-idempotent, at the cost of occasionally double-voting if the acknowledgement from the server is lost
  • naïvely reconnect and re-send all un-confirmed changes

davidje13 avatar Jul 21 '24 15:07 davidje13