Querying DNS seeds too frequently

ajtowns commented at 9:10 am on February 18, 2019: member

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?

fanquake added the label P2P on Feb 18, 2019

naumenkogs commented at 5:49 am on February 27, 2019: member

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?

ajtowns commented at 7:27 am on February 28, 2019: member

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?

fanquake closed this on May 29, 2020

sidhujag referenced this in commit 4f7ea77c81 on May 31, 2020

DrahtBot locked this on Feb 15, 2022

Querying DNS seeds too frequently #15434