[bittorrent] DHT - Clarifying the spec
torrent at blinkenlights.ch
Fri Mar 2 15:59:25 EST 2007
> 1) Nodes that stop responding:
> Firstly, there is no retrying of messages as said in the spec.
Yes, re-sending the query does not make much sense IF your node knows
enough other nodes (maybe with a 'worse' distance..)
> 2) Replacement nodes
> I propose that at most 2 nodes be kept in the cache.
Sounds okay. My current implementation works just fine without any
> 3) Different NodeID's in the response
> If you send a message to a node and the response contains a differnt nodeid
> to the one you were expecting, you should accept the new nodeid as being the
> correct one and update your reference to that nodeid.
Disagreed: Kademlia prefers 'old/stable' nodes to make it
harder to 'hijack' an hack.
If a node just happened to change its own ID, we should ignore the reply
and *remove* the node from our own routing table.
(Because we know that the old ID is dead anyway...)
> 4) Finding close nodes
> To find nodes close to yourself, send a FindPeers message to the K closest
> nodes in your routing table with the target nodeid being the nodeid of your
> client. I.e. if my nodeid is 12345 then i should send a message to my 8
> closest neighbours in the routing table asking them for nodes that are close
> to 12345.
| To join the network, a node u must have a contact to an already
| participating node w. u inserts w into the appropriate k-bucket. u then
| performs a node lookup for its own node ID. Finally, u refreshes all
| k-buckets further away than its closest neighbor. During the refreshes,
| u both populates its own k-buckets and inserts itself into other nodes'
| k-buckets as necessary.
5) -> see 6
> 6) Sending node information
> You should never send a nodes information as part of a FindNode response or
> GetPeers response unless you have verified that the node is good. It must
> have responded to at least 1 message in the past and should also pass the
> criteria in the spec for being classified as "good".
Yes. This filters out firewalled peers. Sadly not all DHT clients are
doing this :-(
> 7) Transaction IDs
> Under no circumstances should the transaction id be truncated or
> expanded or converted from a bencoded number to bencoded string or vice
My implementation creates singe-char transaction IDs but also accepts
longer IDs (and never touches them)
> 8) Token's
> Tokens are similar to transaction id's. They should be treated as a value
> that should be returned exactly as is to the original sender. They should
> not be truncated, expanded or converted to a different bencoded type. You
> should assume that a token can be any of the bencoded types.
I think a token should always be a string.
Using the sha1-hash-method (as mainline does) makes sense.
(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.
More information about the BitTorrent