client/network: Expose kbuckets via RPC

[mxinden]

Motivation

I would like to find answers to the following questions to better understand the Kademlia / Polkadot DHTs as well as hopefully reduce lookup times in the long run.

1. What does the Kusama / Polkadot DHT topology look like? How well are nodes (validators & sentries) connected? How many nodes do close kbuckets contain? ...

2. How many addresses do nodes in the kbuckets have? How many of those are public / private? How many of those are routable? Do two nodes derive the same addresses for a third node?

Possible way forward

I would suggest exposing the entire routing table of each DHT via an RPC endpoint. I am currently just extending the NetworkState struct, but I am also fine with introducing a new RPC endpoint.

This is meant to be used for debugging purposes only.

@@ -49,6 +51,7 @@ pub struct NetworkState {
        pub average_upload_per_sec: u64,
        /// State of the peerset manager.
        pub peerset: serde_json::Value,
+       pub kademlia_kbuckets: Vec<(ProtocolId, Vec<Vec<(PeerId, Vec<Multiaddr>)>>)>,
 }

---

Do people have opinions / objections? If not, I will file a pull-request.

//CC @tomaka @romanb

[tomaka]

If it's for debugging purposes only, feel free to extend NetworkState indeed.

[mxinden]

With #7104 the number of peers per bucket is now exposed via Prometheus. This is good enough for my use-case, thus I am closing here.