-
Notifications
You must be signed in to change notification settings - Fork 4
Description
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)