Currently, nodes will always perform a lookupCheck (FIND_PEER request where receiver should reply with at least 1 peer record) before a peer is added to the routing table, and when refreshing the routing table.
This check should be performed only if the routing table is well populated. Otherwise, it is tricky to bootstrap a new DHT network as the first peers start with an empty routing table, and are unable to provide peer to others when requested by the lookupCheck.
The check will be skipped if the routing table contains less than bucketSize peers, which means that no bucket can be full. It implies that unresponsive peers making it to the routing table because the check was skipped will get evicted once bucketSize peers are present in the routing table, and they won't prevent well behaving peers from replacing them in the routing table.
Currently, nodes will always perform a
lookupCheck(FIND_PEERrequest where receiver should reply with at least 1 peer record) before a peer is added to the routing table, and when refreshing the routing table.This check should be performed only if the routing table is well populated. Otherwise, it is tricky to bootstrap a new DHT network as the first peers start with an empty routing table, and are unable to provide peer to others when requested by the
lookupCheck.The check will be skipped if the routing table contains less than
bucketSizepeers, which means that no bucket can be full. It implies that unresponsive peers making it to the routing table because the check was skipped will get evicted oncebucketSizepeers are present in the routing table, and they won't prevent well behaving peers from replacing them in the routing table.