Skip to content

Kad clarification #692

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Kad clarification #692

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d5a9c37
Clarify PUT_VALUE response
Ben-PH Aug 15, 2025
362817d
Express e.g. bootstrap algo. in pseudocode
Ben-PH Aug 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions kad-dht/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -368,10 +368,17 @@ the wire format and keep their routing table up-to-date, especially with peers
closest to themselves.

The process runs once on startup, then periodically with a configurable
frequency (default: 10 minutes). On every run, we generate a random peer ID for
every non-empty routing table's k-bucket and we look it up via the process
defined in [peer routing](#peer-routing). Peers encountered throughout the
search are inserted in the routing table, as per usual business.
frequency (default: 10 minutes):

```
if routing table is not empty:
for each k-bucket in the routing table:
create a $PEER_ID for said k-bucket using an RNG
do the normal <findNode($PEER_ID)>
```
The idea here, is that peers encountered throughout the find-node process
as defined in [peer routing](#peer-routing), are inserted into the routing table,
as per usual business.
Comment on lines +371 to +381
Copy link
Contributor

@guillaumemichel guillaumemichel Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the current text clearer and more concise.


In addition, to improve awareness of nodes close to oneself, implementations
should include a lookup for their own peer ID.
Expand Down Expand Up @@ -497,8 +504,7 @@ These are the requirements for each `MessageType`:

* `PUT_VALUE`: In the request `record` is set to the record to be stored and `key`
on `Message` is set to equal `key` of the `Record`. The target node validates
`record`, and if it is valid, it stores it in the datastore and as a response
echoes the request.
`record`, and if it is [valid, it then selects](#entry-validation) the value to be stored, and stores it in the datastore. As a response, the request is echoed, with the `record` updated if the selection makes a change.
Copy link
Contributor

@guillaumemichel guillaumemichel Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`record`, and if it is [valid, it then selects](#entry-validation) the value to be stored, and stores it in the datastore. As a response, the request is echoed, with the `record` updated if the selection makes a change.
`record`, and if it is valid and newer than any existing record for `key`, it
stores it in the datastore and responds by echoing back the request.


* `GET_PROVIDERS`: In the request `key` is set to a CID. The target node
returns the closest known `providerPeers` (if any) and the `k` closest known
Expand Down