-
Notifications
You must be signed in to change notification settings - Fork 699
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
Make public addresses go first in authority discovery DHT records #3757
Conversation
Some(address) | ||
} | ||
})) | ||
.filter(move |address| { |
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.
Not sure, may be we should always publish public addresses provided by user even if they are non-global.
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.
dq: I see we have a public_non_global_ips
flag which allows us to publish non-global IP addresse.
When would we want to publish non-global-ips? There is a high chance that a non-global ip could not be reached from the other peers.
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 was thinking about a testnet in a private network case. But we can also use public_non_global_ips
flag for this.
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.
Yeah private network. When you run it locally on your computer, you also need authority discovery to work ;)
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.
LGTM! Nice one 👍
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.
Ty!
One thing I'm not sure if we are already doing it, could we ensure that external_addresses
contains the listen addresses? Maybe we could even have an extra function for getting the listen addresses to have in the end, [public addresses, listen addresses, external addresses].
Some(address) | ||
} | ||
})) | ||
.filter(move |address| { |
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.
Yeah private network. When you run it locally on your computer, you also need authority discovery to work ;)
Do you mean [public addresses, external addresses, listen addresses]? cc @bkchr |
IDK :D I mean this was more some proposal by me. Also should not block this pr BTW.
Listen addresses are more "trusted" than external addresses as you can just query your local network devices to get their ip addresses etc. For validators which should be exposed to the internet, the listen addresses should also give you the correct ip addresses directly. If the operator is giving public addresses, I assume that listen and public will probably be the same. |
We can address it in a follow-up PR. Personally, I would refrain from adding listen addresses as they contain all the interfaces (including 127.0.0.1 and private networks), and it should be enough to have just one valid Identify response from a remote peer to learn a valid external address. We should take into account address translation done by libp2p (it assign a listen address port to discovered external addresses) to make an informed decision though. |
…ritytech#3757) Make sure explicitly set by the operator public addresses go first in the authority discovery DHT records. Also update `Discovery` behavior to eliminate duplicates in the returned addresses. This PR should improve situation with paritytech#3519. Obsoletes paritytech#3657.
Make sure explicitly set by the operator public addresses go first in the authority discovery DHT records.
Also update
Discovery
behavior to eliminate duplicates in the returned addresses.This PR should improve situation with #3519.
Obsoletes #3657.