fix: track closest peers separately from main routing table #2748
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 withKEEP_ALIVE
so we maintain connections to them, which will ensure we propagate changes in our PeerInfo to those peers most likely to answerFIND_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