Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: grow routing table trie towards node kad-id #2747

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

achingbrain
Copy link
Member

Instead of having a balance trie, grow the routing table towards the current node's kad-id.

This gives a better knowledge of the network as we get closer to our own kad-id.

The previous behaviour can be replicated by setting prefixLength and selfPrefixLength to the same value.

Change checklist

  • 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)
  • I have added tests that prove my fix is effective or that my feature works

Instead of having a balance trie, grow the routing table towards
the current node's kad-id.

This gives a better knowledge of the network as we get closer to
our own kad-id.

The previous behaviour can be replicated by setting `prefixLength`
and `selfPrefixLength` to the same value.
@achingbrain achingbrain requested a review from a team as a code owner October 3, 2024 11:49
@achingbrain
Copy link
Member Author

Need to verify if this actually makes any difference.

Because we have a prefix-trie, the trie only grows deeper if the kad-ids encountered share growing prefixes. There will be plenty of peers encountered that have xor-closer kad ids to the root node but will be omitted because the shared bytes are not in the prefix.

That is, given the kad id:

000000

All of these are equally xor-distanced, but only the first would be included in the deeper section of the trie due to the shared bit being in the prefix:

011111
101111
110111
111011
111101
111110

Using a prefix is probably good enough to ensure a reasonable starting point for a query for an arbitrary kad-id, but it may not help when trying to discover more of the kad-space local to the node's peer id.

@achingbrain achingbrain marked this pull request as draft October 4, 2024 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant