-
Notifications
You must be signed in to change notification settings - Fork 353
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
Add burst guard to macOS route monitor #5225
Conversation
DES-384 Debounce route messages
It's difficult to get predictable results now, since we end up changing routes at the same time as the system adds or removes routes. Reusing the "burst guard" from the Windows routing code would likely help with this. We should perhaps still synthesize a "default route removed" event whenever a network switch occurs to deal with DNS/macOS's connectivity check. |
cce7f10
to
c192a3d
Compare
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.
Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dlon)
talpid-routing/src/debounce.rs
line 93 at r1 (raw file):
/// Asynchronously trigger burst pub fn trigger(&self) { self.sender.send(BurstGuardEvent::Trigger).unwrap();
This shouldn't unwrap, or stop
and stop_nonblocking
should take consume self
instead of taking a reference.
talpid-routing/src/unix/macos/mod.rs
line 331 at r1 (raw file):
| Ok(RouteSocketMessage::ChangeRoute(_)) | Ok(RouteSocketMessage::AddAddress(_) | RouteSocketMessage::DeleteAddress(_)) => { self.update_trigger.trigger();
Ideally, the routes would be coalesced and we'd only react to changes in default routes - there's no need to take action if default routes have not been changed.
c192a3d
to
dc157f6
Compare
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.
Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dlon)
7d367f2
to
1582b7c
Compare
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.
Reviewable status: 4 of 6 files reviewed, 1 unresolved discussion (waiting on @pinkisemils)
talpid-routing/src/debounce.rs
line 93 at r1 (raw file):
Previously, pinkisemils (Emīls Piņķis) wrote…
This shouldn't unwrap, or
stop
andstop_nonblocking
should take consumeself
instead of taking a reference.
Done.
1582b7c
to
156c60d
Compare
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.
Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
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.
Reviewed 3 of 6 files at r1, 1 of 1 files at r2, 2 of 2 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
156c60d
to
4399583
Compare
The route monitor currently immediately reacts to any route change. What happens is somewhat unpredictable because we're likely changing the routing table at the same time as the OS. We're also making many unnecessary changes to the routing table, and we might potentially end up constantly updating routes in a tight loop.
The PR fixes these issues by triggering route changes only after a minimum interval of time has elapsed.
Close DES-384.
This change is