core/: Concurrent connection attempts - aka. happy eyeball #1896
Comments
|
I checked the implementation of the connection pool, which may be a lot of work. At present, we can use |
mxinden
changed the title
|
I am re-opening this issue. While complex for sure, it would greatly benefit hole punching. When two peers coordinate a hole punch via the Direct Connection Upgrade through Relay protocol, each peer sends the remote a list of protocols to dial. Given that both sides need to simultaneously dial an address in order for a hole punch to suceed, one can not expect a high hole punch success rate when trying each address sequentially. Given that rust-libp2p does not support parallel dialing today the rust-libp2p DCUtR implementation only attempts to dial the first address provided by the remote peer. Though it could instead emit multiple |
mxinden
changed the title
mxinden
changed the title
Concurrently dial address candidates within a single dial attempt. Main motivation for this feature is to increase success rate on hole punching (see #1896 (comment) for details). Though, as a nice side effect, as one would expect, it does improve connection establishment time. Cleanups and fixes done along the way: - Merge `pool.rs` and `manager.rs`. - Instead of manually implementing state machines in `task.rs` use `async/await`. - Fix bug where `NetworkBehaviour::inject_connection_closed` is called without a previous `NetworkBehaviour::inject_connection_established` (see #2242). - Return handler to behaviour on incoming connection limit error. Missed in #2242.
|
Implemented in #2248. |
Concurrently dial address candidates within a single dial attempt. Main motivation for this feature is to increase success rate on hole punching (see libp2p/rust-libp2p#1896 (comment) for details). Though, as a nice side effect, as one would expect, it does improve connection establishment time. Cleanups and fixes done along the way: - Merge `pool.rs` and `manager.rs`. - Instead of manually implementing state machines in `task.rs` use `async/await`. - Fix bug where `NetworkBehaviour::inject_connection_closed` is called without a previous `NetworkBehaviour::inject_connection_established` (see libp2p/rust-libp2p#2242). - Return handler to behaviour on incoming connection limit error. Missed in libp2p/rust-libp2p#2242.
|
Cross referencing libp2p/go-libp2p#1785 by @marten-seemann here. I think long-term rust-libp2p should adopt an advanced address prioritization like go-libp2p. |
|
Onw property that I'd like to point out is that currently, we use transports in the order they are combined in. That is nice IMO. |
|
On the matter of smart dialing mechanism, corresponding work on the Go side: libp2p/go-libp2p#2260 |
I noticed that libp2p currently only tries next address when one address fails, which causes some users to wait a long time when trying to connect to an unavailable ipv6 address.
Maybe we can try to use a fast fallback strategy like happy eyeballs v2 to quickly connect to available addresses.
I don't know if there are some special reasons that limit connection strategy of libp2p, if not, I will be happy to implement one.
The text was updated successfully, but these errors were encountered: