-
Notifications
You must be signed in to change notification settings - Fork 339
feat(iroh): ping paths and trigger holepunching on networkchange #3796
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -368,6 +368,28 @@ impl RemoteStateActor { | |
| }; | ||
| tx.send(info).ok(); | ||
| } | ||
| RemoteStateMessage::NetworkChange { is_major } => { | ||
| self.handle_network_change(is_major); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| fn handle_network_change(&mut self, is_major: bool) { | ||
| for conn in self.connections.values() { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like I've forgotten half the things, I'm not really sure why we are sending pings today, because I don't think we can do anything with the resulting behaviour. Each path has it's keep-alive and idle-timeout already set. Sending an explicit ping will not change much: the idle timers are already set and will fire. Sending something now won't change that much I think?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the idea is to make sure we have new information as early as possible |
||
| if let Some(quinn_conn) = conn.handle.upgrade() { | ||
| for (path_id, addr) in &conn.open_paths { | ||
| if let Some(path) = quinn_conn.path(*path_id) { | ||
| // Ping the current path | ||
| if let Err(err) = path.ping() { | ||
| warn!(%err, ?path_id, ?addr, "failed to ping path"); | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if is_major { | ||
| self.trigger_holepunching(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so this code-path trigges holepunching less often than the watcher for the local addrs? but otherwise does the same? it seems more like the is_major detection should be added to |
||
| } | ||
| } | ||
|
|
||
|
|
@@ -1175,6 +1197,8 @@ pub(crate) enum RemoteStateMessage { | |
| /// | ||
| /// This currently only includes a list of all known transport addresses for the remote. | ||
| RemoteInfo(oneshot::Sender<RemoteInfo>), | ||
| /// The network status has changed in some way | ||
| NetworkChange { is_major: bool }, | ||
| } | ||
|
|
||
| /// A handle to a [`RemoteStateActor`]. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not do this with the local addr watcher? I don't like having two mechanisms for this, and a watcher seemed nice.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addr change update happens a lot later, this is why I added this mechanism, and it also happens for potentially other reasons. The addr change will happen eventually when net report finishes, but we don't need to wait for that, to already know we want to recheck our connections in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. could we more often update our local addrs? i don't think if the interfaces change that we need to wait until we've also run netcheck until we get updates. I'd like to receive them all as quickly as possible, but still only via one API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one day, but that would require the much bigger refactor of netreport to be more stream based, which will not happen any time soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to accept this technical debt :)
It's annoyed me for a while though so hopefully this will motivate me to get round to improving this soon.