Currently, websocket-bridge only keeps a session alive for as long as the websocket for that session is connected. However, that websocket could be disconnected at any time for various reasons, such as client a client network change, a proxy- or firewall-imposed timeout, etc.
We should add support for persisting sessions for a period of time after the websocket closes, giving the client time to try reconnecting, at which point the session would be associated with the new websocket. This would probably involve sending a secret to the client when it first connects, which the client could provide on reconnect to prove that it owns the session.
In order to make this completely seamless and avoid any message loss, both the client and the server may need to buffer unacknowledged messages, send acknowledgements for all received messages, and resend messages on reconnect. We could even persist the server-side session state in a database of some kind to handle server failover, although at that point we might as well use an existing distributed event store such as Kafka.
Currently,
websocket-bridgeonly keeps a session alive for as long as the websocket for that session is connected. However, that websocket could be disconnected at any time for various reasons, such as client a client network change, a proxy- or firewall-imposed timeout, etc.We should add support for persisting sessions for a period of time after the websocket closes, giving the client time to try reconnecting, at which point the session would be associated with the new websocket. This would probably involve sending a secret to the client when it first connects, which the client could provide on reconnect to prove that it owns the session.
In order to make this completely seamless and avoid any message loss, both the client and the server may need to buffer unacknowledged messages, send acknowledgements for all received messages, and resend messages on reconnect. We could even persist the server-side session state in a database of some kind to handle server failover, although at that point we might as well use an existing distributed event store such as Kafka.