You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/routing/kad-dht.md
+31-4Lines changed: 31 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -281,16 +281,43 @@ It is recommended that the maximum number of in-flight requests (denoted by
281
281
282
282
## Peer Routing
283
283
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.
285
287
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`
287
289
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.
289
295
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.
291
316
292
317
### Signed Peer Records
293
318
319
+
`FIXME`: Signed Peer Records are not yet implemented in the IPFS Kademlia DHT.
0 commit comments