-
Notifications
You must be signed in to change notification settings - Fork 448
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
Improve announced addresses #769
Comments
@jacobheun let me know your thoughts on this. 🏁 are the points where we need a decision |
With this approach, how would you announce your local network addresses? Right now announce addresses are stringified multiaddrs, how would a user generate this for configuration? I'd really just prefer to be able to pass a sorter/filter function for this, because it makes it much easier to provide fine grained control of the announced addresses without risking some configuration / environment values from adding "surprise" values.
I'm not sure I get the 2 step approach. It sounds like you're proposing two waves of dials, public and then private as a fallback? If so, I think this is unnecessary. We should prioritize addresses by public first then private, and we should also really expose a filter for people to be able to custom sort addresses. Additionally, we just need to add multiaddr confidence and denylists, as they'll solve these problems and give us more functionality in general. This would solve problems like websockets attempting to connect to a local ip:port combo when there is no local server there. re: migration, the only thing that should really "break" here is that we shouldn't continue to dial addresses that fail, we need to add the dial backoff back in (this was missed during the async/await transition). |
Also, @vasco-santos have you looked at the way go-libp2p composes the announced addresses? It would be helpful to document that here so we can clarify any differences. |
In the same way they currently can use the
I think you are right! It seems a better approach to have a custom sort and a custom filter. We can default for not announcing private addresses, but users can overwrite the function.
Yes. The main goal here was to avoid using dial tokens if not needed. But I guess we can postpone thinking about this type of optimization.
No, but I will have a look and update this |
So, taking into account the above discussion, what I think we should do is:
Regarding I am expecting the following options: {
addresses: {
announceFilter: () => []
},
dialer: {
addressFilter: () => [],
addrerrSorter: () => []
}
} |
For dialing I think implementing the ConnectionGater, libp2p/go-libp2p#872, is going to be the best approach here, we can create a default Gater similar to libp2p/go-libp2p#1005. We'll need to figure out how addr sorting would work but this handles filtering easily. I don't remember how Go is prioritizing the dials right now. For announcing, I think the filter function makes sense. |
To be more universal, we may not need to distinguish local address or public address because it's impossible to detect how many NAT layers we have (imaging the Internet is just a local net of the Comosnet). I am working on DynamicRelay, which combines addresses announcement, hole punching and autoRelay.
|
Port of https://github.com/libp2p/go-libp2p-core/blob/master/connmgr/gater.go Adds a new configuration key `connectionGater` which allows denying the dialing of certain peers, individual multiaddrs and the creation of connections at certain points in the connection flow. Fixes: #175 Refs: #744 Refs: #769 Co-authored-by: mzdws <[email protected]>
Closing as completed |
This issue aims to find the best solution for announced addresses.
Libp2p is not controlling in any way the announced addresses. This means that users will need to properly configure them, in order to not announce not diable addresses. Moreover, we do not have any multiaddr confidence yet.
In this moment, libp2p announces its addresses as: Union between all listen addresses and provided announce addresses, filtering out provided noAnnounce addresses.
Listen addresses filtering
One of the common issues it to announce local network addresses. While uses cases that leverage these addresses exist, they are not the most common and they are easy to predict (MDNS discovery, or manual dials / bootstrap).
🏁 The best approach is defaulting to not announcing local network addresses unless explicitly added as announce addresses. This would result in: Union between all non-local listen addresses and provided announce addresses, filtering out provided noAnnounce addresses. This will result in identify not announcing local addresses that might get propagated from other peers.
Manual dials and bootstrap nodes rely on previously provided addresses. If a node needs to connect to other nodes in the local network, these will be added to the AddressBook anyway and there will be no issue. For MDNS, we can also add the local addresses in the listen addresses for the query responses.
Dial improvements
As there will be older nodes on the network, we should also try to improve the dialer to avoid using undiable addresses provided from older nodes.
While we do not have multiaddr confidence, we can also slightly improve the dialer. There are two angles we can look. The dial request can sort the known multiaddrs and try the locals in the end. But, if enough tokens it might try locals in a first batch. We can probably do the dial in 2 steps, first try out all non local addresses and then the local ones.
🏁If a combination of non local and local addresses exist, the probability that the local addr work is not high. This way, I think we can probably take the 2 steps dial.
Migration
This change should not have big consequences in working systems as they need to be relying on non local addresses. Anyway, people experimenting with local projects or local setups will probably break as a result of this change.
This should be well documented in the next migration guide.
The text was updated successfully, but these errors were encountered: