-
Notifications
You must be signed in to change notification settings - Fork 445
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
Circuit relay - reconnect to peers we have reservations on #1955
Labels
kind/enhancement
A net-new feature or improvement to an existing feature
Comments
Thoughts, based on the hypothesis presented:
|
I think this relates to #1953 - i.e. as a general rule, if we've successfully dialled the peer recently, but we are no longer connected to them, we should prioritize dialling those peers and conversely if we have dialled a peer but failed recently, then those should be de-prioritized. |
maschad
added
kind/enhancement
A net-new feature or improvement to an existing feature
and removed
need/triage
Needs initial labeling and prioritization
labels
Sep 12, 2023
Closed by #2031 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we have a reservation on a relay, and we lose connectivity to that relay, we should make an effort to reconnect to the same relay before searching for other relays to make a reservation on.
This is because making a new reservation will change our multiaddrs which impacts things like DHT provider records which will now be out of date just because our WiFi was a bit flaky for a time or we closed our laptop lid.
The text was updated successfully, but these errors were encountered: