问题
Closest question to this I think.
One obvious method of structuring a routing table is to simply maintain a literal table. Map(XOR,Node)
Kademlia discusses the use of 'Buckets' which are organised by the most significant bit of the XOR. What is the actual purpose of 'buckets'? Why mess around with 'longest prefix' when we can simply hold the 'actual' XOR as a key in a map?
Obviously the map could potentially be 2^160 large, but we could use some heuristics to limit the size of the map, rather than implementing some arbitrary bucket concept? In any case (buckets or not) when searching for a nodeId close to the one we've been asked to find, we still have to iterate through all nodes in the table and do an XOR on each?
What am I missing?
回答1:
One obvious method of structuring a routing table is to simply maintain a literal table. Map(XOR,Node)
I read the key is xor but the xor of what? xor takes two argument:
distance = xor(hash, peerid)
What is the actual purpose of 'buckets'?
k-bukcets allow to speed the following python code:
nsmallest(k, peers, key=functools.partial(operator.xor, hash))
That is find the closest peers to a given hash.
Why mess around with 'longest prefix' when we can simply hold the 'actual' XOR as a key in a map?
Like I said, above you can not store the xor value of every possible hash.
when searching for a nodeId close to the one we've been asked to find, we still have to iterate through all nodes in the table and do an XOR on each?
That the thing with k-buckets you don't need to iterate over the whole map to find the closest peers, because peers hash aka. peerid are organized by prefix and you know that the nearest peers share the same prefix as the given hash.
Why use Buckets and not a map?
You can use a map instead of k-bucket.
来源：https://stackoverflow.com/questions/52779558/dht-routing-table-why-use-buckets-and-not-a-map