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

Net: Resend previously-failed-to-send messages on reconnect #305

Open
solardiz opened this issue Feb 25, 2024 · 1 comment
Open

Net: Resend previously-failed-to-send messages on reconnect #305

solardiz opened this issue Feb 25, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@solardiz
Copy link
Contributor

Nov 9, 2022

Right now, we first read a message from kmsg, then try to send it. If the sending fails, we'd reconnect and would try reading/sending further messages, but that one is already lost. We could instead resend it upon reconnect.

Further, we find out of a connection failure with a delay - when attempt to send a message fails, it means the previous one could have failed to actually be sent too - but our non-blocking call just buffered it. We could maybe preserve the contents of socket buffer (non-acknowledged) and resend that upon reconnect. This is tricky and it needs research. There's also risk of duplicating messages in this way (not acknowledged does not mean not received), so maybe this should somehow integrate with replay protection.

We could want to split this issue in two (for the above paragraphs).

@solardiz
Copy link
Contributor Author

Nov 10, 2022

Right now, we first read a message from kmsg, then try to send it. If the sending fails, we'd reconnect and would try reading/sending further messages, but that one is already lost. We could instead resend it upon reconnect.

This is now implemented. As expected, one message is getting lost anyway because of the issue described in the second paragraph (quoted below), but previously multiple messages were getting lost (one per invocation of the read/send loop while the connection couldn't be re-established).

Further, we find out of a connection failure with a delay - when attempt to send a message fails, it means the previous one could have failed to actually be sent too - but our non-blocking call just buffered it. We could maybe preserve the contents of socket buffer (non-acknowledged) and resend that upon reconnect.

It's even trickier than that: the socket buffer contains already encrypted data, and the encryption would need to be different upon reconnect (different ephemeral key(s), different message number within the session). Maybe we could merely treat non-empty buffer as a Boolean, and plan on resending (and re-encrypting first) the last message we had sent to the socket.

@solardiz solardiz added the enhancement New feature or request label Feb 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant