-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrieve queued message after close #94
Comments
The same will happen with messages that are already sent to TCP but not received if the peer drops the connection. These messages are not recoverable anymore. That's the reason why we don't try to recover messages from our internal queue. This would be false sense of non-loss guarantee. Closing of TCP connection without closing handshake may result in data loss regardless of our implementation. We still guarantee delivery of messages that are sent before closing handshake if the handshake is performed clearly. |
Yes I understand this principle, with TCP you can't know for sure that you message was received until it is acked. But there is no reason why you shouldn't allow the user to retrieve these unsent messages. These unsent messages are usefull because you know for sure that they were never sent to the peer. Take for instance a client that must make sure that every request is followed by a reply. After a connection failure followed by a reconnection, the client must resolve the state of the in-flight messages that might have been received by the peer (e.g. check with the peer if it received each message). Allowing the user to recover the messages from the queue means that the client has to do less work resolving those messages (because there are less messages to resolve). |
If you did not recover the message, how do you know it wasn't permanently lost? |
You need a mechanism provided by the peer. In my case every request that I send to the user has a unique id. So I can check with the peer for the operations that were executed using this unique id. So I maintain a list of every request and I correlate them with a reply until the connection crashes. When the connection crash, I reconnect the socket then I make a list of in-flight request that might or might not have been completed and then I validate each request individually using the previously mentioned mechanism. |
I'm closing this in favor of #96. Indeed if the websocket supports sending |
As far as I understand, queued messages are lost if the websocket connection dies or is closed. It would helpful to provide a mechanism for the user to retrieve these queued messages.
The text was updated successfully, but these errors were encountered: