-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
autonat: don't change status on dial request refused #2225
Conversation
@marten-seemann |
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.
Yes, I'd like to schedule the next attempt earlier. Not sure if a bool on the struct would be the nicest way to solve this though, can we just do this in the loop?
p2p/host/autonat/autonat.go
Outdated
// a dial may be refused for reasons like being rate limited. We don't want to change our NAT status based | ||
// on this. We just schedule the next probe sooner | ||
if as.confidence == maxConfidence { | ||
as.confidence-- |
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.
- Why are we decreasing the confidence when a dial is refused?
- I don't see any logic here to schedule the next probe sooner.
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.
this hacky way is also used here
If confidence is not maximum the next probe will be done at retryInterval(1 minute) and not refreshTime(15minute)
I'll see if I can make that happen without keeping a bool around.
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 changed it to retry immediately. Is this approach better?
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 have a short delay? I’d like to avoid the situation where all servers are at their limit and clients just keep churning through their list.
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.
a bool seems like the simplest way to achive this 😅
that's what I've implemented.
p2p/host/autonat/autonat.go
Outdated
if !ok { | ||
return | ||
} | ||
as.recordObservation(result) | ||
if IsDialRefused(err) { | ||
as.retryProbe = true |
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.
Why not just pass this as a parameter to scheduleProbe
?
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 changed it to pass it as a parameter but why is this better?
scheduleProbe
is already making the scheduling decision based on params set on the struct like as.lastInbound
why handle this info separately?
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.
Usually I try to keep as little members as possible, but you're right, there seems to be precedent here for not following this principle.
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 agree with your logic, it is better to have this state have as little visibility as possible. We can keep this and change the other "precedents" later when we touch that piece.
0bbc8f5
to
e6e7815
Compare
e6e7815
to
08369b6
Compare
We don't want to update autonat reachability status from public to unknown or from private to unknown when peers reply to dial requests with status dial refused.