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

Josef Drexler jd284 at cornell.edu
Thu Nov 16 14:44:36 EST 2006

Adrian Ulrich wrote:
>>Well, memory isn't so much the problem, you're right, but rather that if we 
>>have a peer for it, the specs say that we reply with the peer info even if 
>>we'd have much better. [...]
> To find peers for info-hash X you are supposed to send
> 'find_node' requests until you do not get any better peers
> as an response. (= You've reached a dead end -> You'll know the
> K-closest nodes!). Only after reaching the dead end you are supposed
> to send a get_peers request. (or do an announce)

That's less efficient than using the built-in "find_node" feature of the 
"get_peers" message though, because you end up asking the last few nodes in 
your search first for closer nodes with "find_node", and when you see there 
aren't any, you ask again for peers with "get_peers" and finally announce 

So using "get_peers" from the start eliminates some failed "find_node" 
requests.  While adding some overhead to all nodes so queried (to create the 
token), the reduced network usage seems to make up for that.  Creating the 
token should be a cheap procedure anyway.

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

I think as long as I don't try to announce to nodes too far from the info 
hash and only announce to the closest 8 I can find, using "get_peers" should 
be just fine.

Josef Drexler

More information about the BitTorrent mailing list