You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd argue this is kind of flawed. We don't need hole punching if we have external addresses. Instead, we should likely gather and use external address candidates as well as allow the user to add their own candidates to the this list.
Likely, this is a left-over from before we landed #3954.
The text was updated successfully, but these errors were encountered:
In a serious of refactorings, we seem to have introduced a bug where we where exchanged the _external_ addresses of our node as part of `libp2p-dcutr`. This is ironically quite pointless. If we have external addresses, then there is no need for hole-punching (i.e. DCUtR).
Instead of gathering external addresses, we use an LRU cache to store our observed addresses. Repeatedly observed addresses will be tried first which should increase the success rate of a hole-punch.
Resolves: #4496.
Pull-Request: #4624.
Description
At the moment, the
dcutr::Behaviour
only sends external addresses to the remote. Seerust-libp2p/protocols/dcutr/src/behaviour_impl.rs
Line 202 in 411a049
rust-libp2p/protocols/dcutr/src/behaviour_impl.rs
Lines 103 to 110 in 411a049
I'd argue this is kind of flawed. We don't need hole punching if we have external addresses. Instead, we should likely gather and use external address candidates as well as allow the user to add their own candidates to the this list.
Likely, this is a left-over from before we landed #3954.
The text was updated successfully, but these errors were encountered: