-
Notifications
You must be signed in to change notification settings - Fork 281
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
feat(snownet): timeout connections if we don't receive a candidate within 10s #3790
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
Terraform Cloud Plan Output
|
Performance Test ResultsTCP
UDP
|
6efae39
to
51661b6
Compare
0771a3d
to
c9b26b7
Compare
@conectado Do you have any idea why these integration tests could fail with this change? Am I not understanding correctly what this timer did? |
Looking at the code it seems equivalent but I don't see the second connection being started in the client logs. I'll later checkout this branch and try to debug it locally. |
28fe87f
to
83cc33e
Compare
6e1d60b
to
f0d7de2
Compare
@@ -51,7 +51,7 @@ | |||
}; | |||
|
|||
devShell = pkgs.mkShell { | |||
packages = [ pkgs.cargo-tauri ]; | |||
packages = [ pkgs.cargo-tauri pkgs.iptables ]; |
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.
To run the test scripts locally, we need iptables.
@@ -29,7 +29,6 @@ use tokio::time::{Interval, MissedTickBehavior}; | |||
// Using str here because Ipv4/6Network doesn't support `const` 🙃 | |||
const IPV4_RESOURCES: &str = "100.96.0.0/11"; | |||
const IPV6_RESOURCES: &str = "fd00:2021:1111:8000::/107"; | |||
const MAX_CONNECTION_REQUEST_DELAY: Duration = Duration::from_secs(10); |
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.
The new timeout in snownet
is also 10s.
253c201
to
81f0205
Compare
This is really strange. I can't reproduce this failure locally. What seems to happen is that the connection never times out despite the relay being restarted. |
a399e10
to
8d7970d
Compare
Ha! It turned out to be a busy-loop when computing the next timeout :) |
8d7970d
to
a61d6d0
Compare
@conectado Ready for review now. I've split up the commits into atomic ones. |
a61d6d0
to
edd804f
Compare
Previously, we had a dedicated timer for this within the tunnel implementation. Now that we have control over the internals of our connection via
snownet
, we can timeout the connection if we don't receive a candidate from the remote within 10s.