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