This PR addresses two things:
fixedseeds
logic from ThreadOpenConnections
, and moves all the DNS seed logic to it’s own thread (previously ThreadDNSAddressSeed
, now ThreadAddressSeed
).fixedseeds
. Instead of adding them to the AddrMan
, making them a potential target for incoming connections by multiple nodes under certain situations (like IBD), it adds them as AddrFecth
peers. That way, nodes will only connect to them for a short amount of time in order to request other nodes’ addresses to connect to, and they will become less of a bottleneckI’m already sold for the refactoring part of this PR. The intertwined logic for dns handling between ThreadOpenConnections
and ThreadDNSAddressSeed
is really annoying, and I’ve had to deal with it previously in https://github.com/bitcoin/bitcoin/pull/28016 and https://github.com/bitcoin/bitcoin/pull/29605.
Light review for now (just the refactoring bit, missing the last commit). So far I wonder if the functionality hasn’t changed more that desired. Before this pull, the fixedseed
logic and the dnsseed
logic were managed by two different threads, meaning that they could run in parallel. The former (which is our last resort) will kick in after a minute of trying other sources for peers. Independently of whether we have tried all of them or not (we may have tried some seed nodes and dns seeds, but not exhausted them). Now, fixedseeds
are run sequentially after dnsseeds
, meaning that they will only trigger after all of them have been tried (and we haven’t achieved our connection count target).
The previous has been acknowledged by @mzumsande. Iterating over all dnsseeds
should take, roughly, about ~60 secs. That is because we query seeds
First pass (Up to https://github.com/bitcoin/bitcoin/pull/26114/commits/952534d4961eff135276533f16d2379ac10c8c26):
net: Make AddrFetch connections to fixed seeds by mzumsande · Pull Request #26114 · bitcoin/bitcoin