[bittorrent] DHT - Clarifying the spec

Alan McGovern alan.mcgovern at gmail.com
Fri Mar 2 14:29:37 EST 2007


Hi,

I've started working on my own implementation of mainline DHT for my client.
There are a fair few inconsistencies in the draft spec and it is missing a
lot of information which is needed to make a good implementation so i was
hoping that if i posted my findings up here, we could all agree on a few
common items and update existing code to respect those changes.

Here's the points i'd like to clarify:
1) Nodes that stop responding:
Firstly, there is no retrying of messages as said in the spec. If a node
doesn't reply to a message, you should mark it as "suspect" not not dead. If
a node fails to respond to 5 or more queries in a row, consider it offline
and so you can remove it from the routing table safely. The timeout for a
message not being responded to should be 30 seconds.

So if after 30 seconds, the node has not sent a response, you should mark
that node as being "suspect" and record that it failed to reply.


2) Replacement nodes
Each bucket holds K nodes (currently 8). The spec calls for a cache of
replacement nodes which are stored in order to replace a node in the bucket
if a node in the bucket should go offline. I propose that at most 2 nodes be
kept in the 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.

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.

5) Adding nodes to the routing table
Nodes should not be added directly to the routing table as being "good"
nodes until they respond to at least 1 message. This stops dead nodes
propagating throughout the network.

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

7) TransactionID's
Transaction id's are ill-defined in the spec. It states that they should be
a single character string yet in the code examples it shows the transaction
id being a bencoded number (i.e. i1234e). The actual transaction ID used
should be irrelevant. Each client should return it exactly as they received
it. Under no circumstances should the transaction id be truncated or
expanded or converted from a bencoded number to bencoded string or vice
versa.

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.

9) Version field
LibTorrent and a number of other DHT clients have implemented a "version"
field into each DHT message. Ideally all clients would follow this scheme so
bugs can be easily traced and reported so they can be fixed. The details are
laid out here<http://www.rasterbar.com/products/libtorrent/dht_extensions.html>:
.

If anyone has any comments on that, or thinks any of it is stupid/idiotic
feel free to say so (but politely ;) ).
Thanks,
Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070302/6d7ec241/attachment.html 


More information about the BitTorrent mailing list