[bittorrent] DHT: How to reply to get_peers when I have neither any peers nor closer nodes?
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.
More information about the BitTorrent