[bittorrent] DHT - Clarifying the spec
arvid at cs.umu.se
arvid at cs.umu.se
Fri Mar 2 18:21:57 EST 2007
Most of these things are mentioned in the spec. See the reference to the
Quoting Alan McGovern <alan.mcgovern at gmail.com>:
> 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.
What makes you think this is a better scheme than the one outlined in the
One optimization that at least uTorrent does is that it has two timeouts on DHT
messages. If a node doesn't respond within the first (short) timeout, the
branch factor is increased by one (temporarily), and when it finally times out
(with the longer timeout) OR responds, the branch factor is decreased by one.
This will let slow nodes live without stalling other requests too much.
> 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.
> 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.
This is just what the paper says.
> 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.
This is also what the paper says (unless I'm mistaken). It's kind of obvious at
least, but maybe it's good to make an explicit statement.
> 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".
Basically the same as (5).
More information about the BitTorrent