-
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
introduce a proper address pipeline #2229
Labels
effort/weeks
Estimated to take multiple weeks
exp/wizard
Extensive knowledge (implications, ramifications) required
P1
High: Likely tackled by core team if no one steps up
Comments
marten-seemann
added
exp/wizard
Extensive knowledge (implications, ramifications) required
P0
Critical: Tackled by core team ASAP
effort/weeks
Estimated to take multiple weeks
labels
Mar 27, 2023
This was referenced Apr 8, 2023
This was referenced May 16, 2023
p-shahi
added
P1
High: Likely tackled by core team if no one steps up
and removed
P0
Critical: Tackled by core team ASAP
labels
May 22, 2023
mergify bot
pushed a commit
to libp2p/rust-libp2p
that referenced
this issue
May 24, 2023
Previously, a `NetworkBehaviour` could report an `AddressScore` for an external address. This score was a `u32` and addresses would be ranked amongst those. In reality, an address is either confirmed to be publicly reachable (via a protocol such as AutoNAT) or merely represents a candidate that might be an external address. In a way, addresses are guilty (private) until proven innocent (publicly reachable). When a `NetworkBehaviour` reports an address candidate, we perform address translation on it to potentially correct for ephemeral ports of TCP. These candidates are then injected back into the `NetworkBehaviour`. Protocols such as AutoNAT can use these addresses as a source for probing their NAT status. Once confirmed, they can emit a `ToSwarm::ExternalAddrConfirmed` event which again will be passed to all `NetworkBehaviour`s. This simplified approach will allow us implement Kademlia's client-mode (#2032) without additional configuration options: As soon as an address is reported as publicly reachable, we can activate server-mode for that connection. Related: #3877. Related: #3953. Related: #2032. Related: libp2p/go-libp2p#2229. Co-authored-by: Max Inden <mail@max-inden.de> Pull-Request: #3954.
Closed
We need something like #2293 to test this. |
umgefahren
pushed a commit
to umgefahren/rust-libp2p
that referenced
this issue
Mar 8, 2024
Previously, a `NetworkBehaviour` could report an `AddressScore` for an external address. This score was a `u32` and addresses would be ranked amongst those. In reality, an address is either confirmed to be publicly reachable (via a protocol such as AutoNAT) or merely represents a candidate that might be an external address. In a way, addresses are guilty (private) until proven innocent (publicly reachable). When a `NetworkBehaviour` reports an address candidate, we perform address translation on it to potentially correct for ephemeral ports of TCP. These candidates are then injected back into the `NetworkBehaviour`. Protocols such as AutoNAT can use these addresses as a source for probing their NAT status. Once confirmed, they can emit a `ToSwarm::ExternalAddrConfirmed` event which again will be passed to all `NetworkBehaviour`s. This simplified approach will allow us implement Kademlia's client-mode (libp2p#2032) without additional configuration options: As soon as an address is reported as publicly reachable, we can activate server-mode for that connection. Related: libp2p#3877. Related: libp2p#3953. Related: libp2p#2032. Related: libp2p/go-libp2p#2229. Co-authored-by: Max Inden <mail@max-inden.de> Pull-Request: libp2p#3954.
This was referenced Nov 25, 2024
This was referenced Dec 1, 2024
The flow here is:
So we have an object that's something like:
We then test these via autonat v2 and send updates on eventbus that includes both new addresses and their reachability changes. |
https://github.com/libp2p/go-libp2p/pull/3075/files Refactors the existing logic enough to make it readable. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
effort/weeks
Estimated to take multiple weeks
exp/wizard
Extensive knowledge (implications, ramifications) required
P1
High: Likely tackled by core team if no one steps up
We need to get a lot smarter about address management. Wrapping / replacing addresses via the
AddrsFactory
doesn't scale.I'm imagining a new service that's responsible for the entire process of address management.
Updated(@sukunrt): Using this issue for tracking:
Tasks
The text was updated successfully, but these errors were encountered: