Skip to content

Bucket refresh algorightm seems to not follow the Kademlia protocol #4

@inetic

Description

@inetic

The Kademlia paper says in the chapter "2.3 Kademlia protocol" second-to-last chapter:

Buckets are generally kept fresh by the traffic or requests traveling through nodes. To handle pathological cases in which there are no lookups for a particular ID range, each node refreshes any bucket to which it has not performed a node lookup in the past hour. Refreshing means picking a random ID in the bucket's range and performing a node search for that ID.

The bittorrent DHT protocol spec. is only slightly different:

Each bucket should maintain a "last changed" property to indicate how "fresh" the contents are. When a node in a bucket is pinged and it responds, or a node is added to a bucket, or a node in a bucket is replaced with another node, the bucket's last changed property should be updated. Buckets that have not been changed in 15 minutes should be "refreshed." This is done by picking a random ID in the range of the bucket and performing a find_nodes search on it. Nodes that are able to receive queries from other nodes usually do not need to refresh buckets often. Nodes that are not able to receive queries from other nodes usually will need to refresh all buckets periodically to ensure there are good nodes in their table when the DHT is needed.

However, what the code seems to be doing is:

  • Go over all 160 buckets even if there is only fewer of them (usually up to 30)
  • Taking a single questionable node (if it exists) and sending it a FindNode request
  • Waiting for REFRESH_INTERVAL_TIMEOUT to go to the next bucket (even if nothing happened in the previous steps)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions