[bittorrent] DHT - Clarifying the spec

Adrian Ulrich torrent at blinkenlights.ch
Fri Mar 2 15:59:25 EST 2007


Hi Alan,


> 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
cache ;-)


> 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.

http://www.scs.stanford.edu/~dm/home/papers/maymounkov:kademlia.ps.gz

|     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
> versa.

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.


Regards,
 Adrian



-- 
 RFC 1925:
   (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 mailing list