feat(kad): configurable bucket size

[guillaumemichel]

Description

Making bucket size configurable. Currently K_VALUE is used by default, and the only way to change the bucket size is to edit the const.

Resolves #5389

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[dariusc93]

/CC @mxinden

[mxinden]

I am not opposed to this change in specific, but want to warn you of introducing yet another configuration option, and thus yet another dimension in which bugs can occur.

Instead of introducing more nobs for users to tweak, I suggest improving the existing, alleviating users from the need to tune nobs in the first place.

libp2p-kad is already very hard to deploy. In my eyes, this makes it even harder. What is the upside of this change? In other words, what is the use-case?

[guillaumemichel]

@mxinden Unfortunately this issue cannot be tackled by any existing nob.

The upside of this change is to allow users to modify the bucket size, which is a system parameter. Currently, it is set to the hardcoded K_VALUE = 20 constant. The Amino DHT has a bucket size of 20 but it isn't the case of all networks (e.g ethereum discv5 has a bucket size of 16).

The issue originated in #5371. TL;DR changing the bucket size can help debug other problems in the network.

Would it help to add to the documentation that this is an advanced nob?

[dariusc93]

Would it help to add to the documentation that this is an advanced nob?

If there is no objections to it, it might be best to document it, but I also do agree that we should also improve what we have too. libp2p spec doesnt restrict us to just a bucket size of 20 as it is the recommended size, but there could be other use cases to increase or decrease it (assuming the end-user knows what they are doing)

[elecbug]

I rewrite what I wrote in #5501 here.

To facilitate the discussion, I would like to add a little bit of what we have researched.

First, in an environment with K_VALUE of 20, one node gets approximately maxed 5K neighbors. It is useful in large IPFS-like environments where at least thousands of nodes communicate, but in small environments, including libp2p alone, when the total number of nodes is significantly less than 5K, a dense P2P network is formed that is meaningless with DHT.

It is thought that these networks can especially hinder the participation of small-sized researchers like us, who use libp2p to create and study nodes with their own server for a small scale, and in fact, we are currently considering a transfer to the Go language.

We started working with Rust, loved it, and would love to continue. I think these modifications will be useful to make people like us more interested in rust-libp2p.

Thanks for reading :)

[AgeManning]

I agree. It seems users find this useful and different kad systems are using different bucket configurations.

It seems like making this configurable will extend the use of rust-libp2p to these discovery mechanisms,

I think its a good addition.

[jxs]

LGTM! Thanks Gui