Skip to content

Commit a5eefc3

Browse files
peer routing
1 parent 3bc396d commit a5eefc3

File tree

1 file changed

+31
-4
lines changed

1 file changed

+31
-4
lines changed

src/routing/kad-dht.md

Lines changed: 31 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -281,16 +281,43 @@ It is recommended that the maximum number of in-flight requests (denoted by
281281

282282
## Peer Routing
283283

284-
DHT Clients that want to be routable must make sure they are in the peerstore of the closest DHT servers to their own PeerID.
284+
Implementations typically provide two interfaces for peer routing using the
285+
`FIND_NODE` RPC: `FindPeer`, which locates a specific Peer ID, and
286+
`GetClosestPeers`, which finds the `k` closest peers to a given key.
285287

286-
When performing a `FIND_NODE` lookup, the client will converge to the closest nodes in XOR distance to the requested PeerID. These nodes are expected to know the multiaddrs of the target peer. The
288+
### `FindPeer`
287289

288-
### `FIND_NODE` Termination
290+
`FindPeer` is the process of discovering the multiaddresses of a given Peer ID.
291+
The requester uses the `FIND_NODE` RPC, including the bytes representation of
292+
the target Peer ID in the `key` field. The lookup eventually converges on the
293+
target Peer ID. The lookup process terminates early if the requester has
294+
established a connection to the target Peer ID.
289295

290-
### Routing to non-DHT Servers
296+
#### Discovering non-DHT Servers
297+
298+
DHT clients that want to remain routable must ensure their multiaddresses are
299+
stored in the peerstore of the DHT Servers closest to them in XOR distance.
300+
Since peerstore entries expire over time, DHT Clients SHOULD periodically
301+
reconnect to their closest DHT servers to prevent their information from being
302+
removed. It is recommended to perform this reconnection every 10 minutes.
303+
304+
When receiving a `FIND_NODE` request for a given Peer ID, DHT Servers MUST
305+
always respond with the information of that Peer ID, if it is included in their
306+
peerstore, even if the target node isn't a DHT Server or only advertises
307+
private addresses.
308+
309+
### `GetClosestPeers`
310+
311+
`GetClosestPeers` also makes use of the `FIND_NODE` RPC, but allows the sender
312+
to look for the `k` closest peers to any key. The `key` provided to `FIND_NODE`
313+
corresponds to the preimage of the Kademlia Identifier.
314+
315+
`GetClosestPeers` is used for Content Routing.
291316

292317
### Signed Peer Records
293318

319+
`FIXME`: Signed Peer Records are not yet implemented in the IPFS Kademlia DHT.
320+
294321
## Content Routing
295322

296323
### Content Kademlia Identifier

0 commit comments

Comments
 (0)