-
Notifications
You must be signed in to change notification settings - Fork 984
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
protocols/kad: Expose kbucket distance range #1680
Conversation
Instead of only returning non-empty kbuckets via `Kademlia::kbuckets`, return empty ones as well. Doing so enables consumers to (1) reason about each and every bucket and (2) depend on a stable order of the buckets.
The only small issue I have with this is that it leaks implementation details. Ideally, the implementation strategy for the buckets should not leak in the public API, but that is what happens when not filtering out empty buckets - empty buckets only exist because of the 256-fixed-array implementation, e.g. I don't think they would be present in an implementation based on a dynamically growing "bucket-tree", what is actually suggested in the paper. Of course, one could artificially "fill up" the gaps in the iterator with empty buckets in that case, but even then there would no longer always be 256 buckets because the ranges covered by the buckets vary in that case, if I remember correctly. Isn't what you're mainly interested in the distances covered by the buckets? The order should always be stable. Maybe exposing the ranges covered by each bucket would be sufficient? If you know which distance each non-empty bucket covers, you also know the "empty space" in-between. |
I agree that my suggestion leaks implementation details. E.g. making @romanb are you suggesting a change along the lines of the following? diff --git a/protocols/kad/src/kbucket.rs b/protocols/kad/src/kbucket.rs
index 2ea7f362..715eedde 100644
--- a/protocols/kad/src/kbucket.rs
+++ b/protocols/kad/src/kbucket.rs
@@ -447,6 +447,14 @@ where
TKey: Clone + AsRef<KeyBytes>,
TVal: Clone
{
+ pub fn min_distance(&self) -> Distance {
+ unimplemented!()
+ }
+
+ pub fn max_distance(&self) -> Distance {
+ unimplemented!()
+ }
+ |
@mxinden Yes, something like that. Or just a single method along the lines of |
This reverts commit eafeee2.
Add `KBucketRef::range` exposing the minimum inclusive and maximum inclusive `Distance` for the bucket
@romanb would you mind taking another look? |
Feel free to update the changelog and merge at your convenience. |
Instead of only returning non-empty kbuckets viaKademlia::kbuckets
,return empty ones as well.
Doing so enables consumers to (1) reason about each and every bucket and(2) depend on a stable order of the buckets.
Add
KBucketRef::range
exposing the minimum inclusive and maximuminclusive
Distance
for the bucketMore specifically within substrate I would like to expose the following metric: