[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 12:56:17 EST 2006

Adrian Ulrich wrote:
>>On a related note (if you don't mind), is there any recommendation on how to 
>>decide whether to track a torrent?  Currently I do it if the info hash falls 
>>in my bucket range, but that means I'm tracking between 400-500 torrents 
>>which seems a little excessive.  Is that a normal number?
> Quote from 109.pdf:
>    To store a key,value pair, a participant locates the k closest nodes
>    to the key and sends them STORE RPCs.
> ..so i guess what you are doing is correct.

Thanks, it's sometimes not obvious how much of the Kademlia specs apply to 
the BT DHT implementation of it.  There's a lot that's left unsaid there.

> I left my DHT-node running for about 3-4 days and didn't even validate
> if my peerid is within the k-closest nodes: Currently i've seen
> announce messages for about 1710 different info hashes.
> It may seem to be excessive but storing the information doesn't really
> use much memory.

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, closer nodes.  So it means that peer information for 
each info hash may be diluted among too many nodes as a result, because 
you'd have to hope that one of the other nodes responds with a list of nodes 
that are actually close to the info hash.  This is especially bad because 
unlike Kademlia, there is no re-sharing of peer information among the 
tracking nodes (which wouldn't work anyway because one can't specify a 
different IP address in the announce), only by the peers re-announcing 
themselves regularly.

Of course we could re-interpret the specs to reply with closer nodes if the 
info hash doesn't fall in our own bucket even if we have peers for it, but 
then there's no point in recording the peers in the first place.  So I reply 
with a "203 Not tracking this torrent" error when I receive such an 
announce_peer message.

Btw, Kademlia mentions a 24 hour expiration for data stored, but that seems 
too long for peer data.  On the other hand, the BT DHT specs mention nothing 
about re-announce periods either.  So how often should I announce to the 
DHT, and when should I expire old peer data?

Currently I announce every 30 minutes and expire peers that I haven't heard 
from for 2 hours.  That seems to be similar to what most regular trackers do.

Josef Drexler

More information about the BitTorrent mailing list