The routing table is a balance trie where the path to the leaf node storing the contact is derived from the prefix of the kad id of the contact.
This makes it great for starting a query because we can quickly find contacts in the kad-vicinity of the target, but it's less good for knowing peers that are in our kad-vicinity, since the bits that make us kad-close to another peer might not be in the prefix.
Currently we track which leaf-node our peer id would be in and tag all contacts in that bucket with KEEP_ALIVE. This misses many potentially much closer peers as their KadIDs do not share the same prefix.
Instead, use a peer distance list that we update whenever a peer successfully completes a PING operation. Periodically check this list and tag the closes peers with KEEP_ALIVE so we maintain connections to them, which will ensure we propagate changes in our PeerInfo to those peers most likely to answer FIND_PEER queries for our data, and remove the tag from peers that have fallen out of the list due to closer peers having been discovered.
Change checklist
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
[x] I have added tests that prove my fix is effective or that my feature works
The routing table is a balance trie where the path to the leaf node storing the contact is derived from the prefix of the kad id of the contact.
This makes it great for starting a query because we can quickly find contacts in the kad-vicinity of the target, but it's less good for knowing peers that are in our kad-vicinity, since the bits that make us kad-close to another peer might not be in the prefix.
Currently we track which leaf-node our peer id would be in and tag all contacts in that bucket with
KEEP_ALIVE. This misses many potentially much closer peers as their KadIDs do not share the same prefix.Instead, use a peer distance list that we update whenever a peer successfully completes a
PINGoperation. Periodically check this list and tag the closes peers withKEEP_ALIVEso we maintain connections to them, which will ensure we propagate changes in our PeerInfo to those peers most likely to answerFIND_PEERqueries for our data, and remove the tag from peers that have fallen out of the list due to closer peers having been discovered.Change checklist