kad-dht/README: Document client mode #392
Conversation
This commit documents the DHT client mode, keeping routing tables clear of clients (laptops), while still allowing clients to utilize the functionality of the DHT.
kad-dht/README.md
Outdated
| When the libp2p Kademlia protocol is run on top of a network of heterogeneous | ||
| nodes, unrestricted nodes should operate in _server mode_ and restricted nodes, | ||
| e.g. those with intermittent availability, high latency, low bandwidth, low | ||
| CPU/RAM/Storage, etc., should operate in _client mode_. | ||
|
|
||
| As an example, running the libp2p Kademlia protocol on top of the Internet, | ||
| publicly routable nodes, e.g. servers in a datacenter, would operate in _server | ||
| mode_ and non-publicly routable nodes, e.g. laptops behind a NAT and firewall, | ||
| would operate in _client mode_. |
There was a problem hiding this comment.
This seems pretty good, although the advice here is all sort of fuzzy and situational. I'm adding some context in case you think it's reasonable to rephrase.
The definition of intermittent availability depends on the parameters of a given kad-dht network (replication factor, republishing periods, record expiration times, etc.). For example, having a laptop with UPnP support behind a NAT that's open for a few hours consecutively is probably a fine DHT server for networks with replication factors high enough to accommodate that (e.g. tuned to assume many nodes disappear after an hour).
The key is basically that nodes should be in client mode if they think they'll ultimately be a drag on the network (e.g. everyone behind a symmetric NAT or firewall), but what that means is up to them. Most implementations should probably do their best to figure this out probabilistically/automatically so that normal users don't have to consider this.
There was a problem hiding this comment.
I'm not sure if this is covered elsewhere in the spec, but networks may also want to add their own rules for routing table membership to exclude bad peers (e.g. those without public IP addresses) so they're not just relying on users correctly setting client mode. However, if using rules they should probably be as symmetric/uniformly applicable as possible to maintain the coherence of the network's routing tables.
There was a problem hiding this comment.
710c499 adds the factors above as examples to take into consideration. I am not sure how to make it less fuzzy without loosing generality and thus not being applicable to all use-cases. Suggestions welcome.
There was a problem hiding this comment.
I'm not sure if this is covered elsewhere in the spec, but networks may also want to add their own rules for routing table membership to exclude bad peers (e.g. those without public IP addresses) so they're not just relying on users correctly setting client mode. However, if using rules they should probably be as symmetric/uniformly applicable as possible to maintain the coherence of the network's routing tables.
Oh, just saw this. I don't think this is covered anywhere. Agreed. I am not sure it needs to be documented though.
|
Thanks for the super quick review @aschmahmann! |
This commit documents the DHT client mode, keeping routing tables clear
of clients (e.g. laptops), while still allowing clients to utilize the
functionality of the DHT.
A note on support across the implementations: Implemented in Go, pending in Rust (libp2p/rust-libp2p#2032), uncertain about other languages.
//CC @aschmahmann and @MarcoPolo