Skip to content
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

Closed
jean-airoldie opened this issue Nov 26, 2019 · 5 comments
Closed

Retrieve queued message after close #94

jean-airoldie opened this issue Nov 26, 2019 · 5 comments

Comments

@jean-airoldie
Copy link

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.

@agalakhov
Copy link
Member

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.

@jean-airoldie
Copy link
Author

jean-airoldie commented Nov 26, 2019

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).

@agalakhov
Copy link
Member

If you did not recover the message, how do you know it wasn't permanently lost?

@jean-airoldie
Copy link
Author

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.

@jean-airoldie
Copy link
Author

I'm closing this in favor of #96. Indeed if the websocket supports sending Bytes, we can cheaply keep a copy of all the pending messages, which would circumvent the need to recover them altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants