Querying DNS seeds too frequently #15434

Despite being running most of the time, and having a database of tens of thousands of peers, my node seems to query the DNS seeds each time I restart it, which doesn't seem ideal from a privacy perspective?

eg from my debug.log:

2018-10-25T18:03:51Z Loaded 70360 addresses from peers.dat  172ms
2018-10-25T18:04:02Z Loading addresses from DNS seeds (could take a while)
2018-10-28T23:00:06Z Loaded 70368 addresses from peers.dat  153ms
2018-10-28T23:00:17Z Loading addresses from DNS seeds (could take a while)
2018-11-18T21:06:11Z Loaded 70033 addresses from peers.dat  1105ms
2018-11-18T21:06:22Z Loading addresses from DNS seeds (could take a while)
2018-12-19T06:37:23Z Loaded 71275 addresses from peers.dat  1953ms
2018-12-19T06:37:34Z Loading addresses from DNS seeds (could take a while)
2018-12-27T08:03:36Z Loaded 71670 addresses from peers.dat  1259ms
2018-12-27T08:03:47Z Loading addresses from DNS seeds (could take a while)
2019-02-18T08:46:48Z Loaded 70040 addresses from peers.dat  165ms
2019-02-18T08:46:59Z Loading addresses from DNS seeds (could take a while)

I think this is due to (1) many of the peers in my peers.dat not being alive, which means that (2) most outgoing connection attempts fail and stall for 5 seconds (nConnectTimeout), so (3) since the DNS seed thread waits for 11 seconds, only 3 or 4 attempts are generally made, with only 0 or 1 peers successfully connecting, so the threshold of 2 or more relevant peers isn't reached.

It might make sense to increase the DNS threads sleep time correspondingly? Something like:

-        if (!interruptNet.sleep_for(std::chrono::seconds(11)))
+        if (!interruptNet.sleep_for(std::chrono::milliseconds(nConnectTimeout * 7)))

perhaps?

What you're saying sounds reasonable. However, I tried to apply your suggested change and it didn't change the behavior for me (but I also have less populated peers.dat). Did you try to apply this change?

What you're saying sounds reasonable. However, I tried to apply your suggested change and it didn't change the behavior for me (but I also have less populated peers.dat). Did you try to apply this change?

Yeah, it worked fine for me, but I didn't try very hard, so getting 2 successes out of ~7 attempts might have just been good luck? I also added a LogPrintf in ThreadOpenConnections() to report outgoing connection attempts; duplicates a -debug=net log messasge, but was less noisy for quick debugging.

I'm getting maybe 20% of outbound attempts succeeding, which if my maths isn't too far off says 8 attempts should be ~50% chance of 2 connections, 18 attempts should give 90% chance, 31 for 99%, and 40 for 99.9%. Though having now tried stopping and restarting a few times in quick succession, I'm getting higher success rates.

Might be better to run a few extra threads that just try to connect to previously seen peers at startup to get reconnected to the network faster?