[bittorrent] DHT: How to reply to get_peers when I have neither any peers nor closer nodes?

Adrian Ulrich torrent at blinkenlights.ch
Thu Nov 16 15:43:14 EST 2006


> That's less efficient than using the built-in "find_node" feature of the 
> "get_peers" message though

But it's the only way to implement a correct 'node lookup' and solves
the problem you described in <455CA641.9030804 at cornell.edu>

Quoted from the '1st International Workshop on Peer-to-peer Systems
2002'-version paper:
http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

 -> 2.3 (node lookup)
  The lookup initiator starts by picking 'a' nodes from its closest
  non-empty 'k'-bucket [...]. The initiator then sends parallel,
  asynchronous FIND_NODE RPCs to the 'a' nodes it has choosen.
  [...]
  If a round of FIND_NODES fails to return a node any closer than
  the closest already seen, the initiator resends the
  FIND_NODE to all of the 'k' closest 
  (= k-closest nodes found)

Using a node lookup (find_nodes) you *will* find the K-closest nodes.
A search using get_peers may or may not return the K-closest nodes.

The overhead using find_nodes is minimal: You don't need to do
a new find_nodes search if you simply would like to get some new
BT-peers:

 #1 Client boots with an empty table
 #2 Client searches the K closest nodes using find_nodes
 #3 Client runs get_peers
 #4 Client maybe even announces itself
 #5 -> 3

(Well: after some hours it may be good to do a find_nodes to the
K-closest nodes to refresh your table)



> the reduced network usage seems to make up for that. 

IMO find_nodes has to be used for a correct Kademlia implementation and
as i said before: The overhead is minimal because you'll endup asking
+8 nodes only after you've lost your routing table somehow.

But the Bittorrent DHT has a different, big problem:
DHT nodes seem to take a VERY LONG time until they die:

I had my DHT implementation running on a static IP for a few days.
The client has now been disabled for + 3 days but i'm still getting
about ~ 8 DHT requests/s !

Why? Looks like some implementations are returning unverified nodes
(= not pinged ; never responded to a request) as a result of
find_node/get_peers requests.

This is very annoying ....


> I'm not certain, but that seems to be the approach most clients out there 
> are taking, because I see far more "get_peers" queries, even for relatively 
> far nodes, than I see "find_node".

There are a lot of broken clients out there sending wrong
transaction-IDs (single char), using empty tokens and sending get_nodes
RPCs to locate close peers ;-)



-- 
            A. Top posters
            Q. What's the most annoying thing on Usenet?



More information about the BitTorrent mailing list