Device Reconnection in Transports #34
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The inactivity timeout used to trigger reconnection will be configurable to the user, even though a default value will be provided. Also remove the unresolved question about whether the feature will be configurable (and how much). It's clear from user feedback that there's a desire for configurability.
The previous version of the RFC stated that a transparent reconnection would generate a single Reconnect event (not preceded by Reconnecting). This caused two issues: it is trickier to implement, and it makes reconnection events inconsistent. Because of these issues and because the Reconnect event on a transparent reconnection was purely for informational purposes (users couldn't act on it in any meaningful way), it was decided to remove that feature from the RFC.
nlebedenco
reviewed
Nov 24, 2021
text/0000-device-reconnection.md
Outdated
| # Prior art | ||
| [prior-art]: #prior-art | ||
|
|
||
| - The QUIC protocol ([RFC 9600](https://datatracker.ietf.org/doc/html/rfc9000)) is a network protocol built over UDP that automatically handles reconnections the same way we do for the base UDP protocol. (Obviously QUIC is much more complex since it also bundles TLS and congestion control.) |
There was a problem hiding this comment.
Typo here. Should read RFC9000 instead of RF9600 the http link is correct though.
Author
There was a problem hiding this comment.
Fixed. Thanks for catching that.
It was determined that these events would be confusing considering the future session reconnection feature that will also have reconnection-related events. Also, there was no use for these events.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Formatted text available here.
This is a bit of an unusual RFC in that it's mostly concerned with a feature being added to UTP. The technical implementation details will probably be of little interest to most NGO developers. But it does expose new events in the transport interface, which is what we're most interested in in terms of feedback (although we'll be happy to receive comments on the rest).
The RFC proposes to expose
ReconnectingandReconnectevents from the transport. The assumption behind exposing these is that they might be useful to NGO to handle lag spikes and short losses of traffic (whether caused by a device reconnection or not). But if the overwhelming feedback is that NGO will never make use of these events, we might reconsider our decision of exposing them (allowing us to avoid being tied to a particular implementation strategy for device reconnection).