-
Notifications
You must be signed in to change notification settings - Fork 773
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
Correct /nat
API for libp2p
#6677
Open
AgeManning
wants to merge
1
commit into
sigp:release-v6.0.1
Choose a base branch
from
AgeManning:correct-nat-metrics
base: release-v6.0.1
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+2
−6
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Nice catch. This is now set in
handle_established_inbound_connection
instead since #6486.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 shouldn't be removed, it tells us when
libp2p-upnp
was able to successfully map the address and port via UPnP on the router and therefore NAT traversal is activated.I had missed the code Jimmy linked it, but we receiving an inbound connection doesn't tell us about our NAT traversal settings in libp2p, we may be reached by a peer with a public address that we established a connection before and so the port may still be mapped in the router right?
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 wasn't sure of when this message actually gets sent.
If this gets sent when upnp worked successfully, then we have some competing conditions about what we say about our libp2p nat being open.
Which is a stronger condition?
UPnP successful or incoming connections?
Both have error cases I think.
To make it simple, I think its easier to reason about with incoming connections. Maybe we have some number of connections (in discovery its 2, i think). If UPnP worked, then I'd expect we would get incoming connections.
The other thing we don't account for is, if after it worked once, we dont check again. Maybe we should also check if we get 0 incoming peers, we should make it as false?
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.
Happy to have some mix if you prefer to keep the UPnP message. Is UPnP the only behaviour that sends this? Could this get sent from other behaviours that might be also fallible?