[bittorrent] DHT - Clarifying the spec

Adrian Ulrich torrent at blinkenlights.ch
Sat Mar 3 04:32:04 EST 2007

> Actually, ignore that one. I thought i read in the kademlia paper that a
> list of spares was kept to replace nodes that die, but after rereading it i
> didn't see that passage :p So i must have misread something before.

No, you are supposed to have a cache because kademlia always prefers
'old' contacts :-)
 '4.1 Optimized contact accounting' talks about it.

> Do i assume that this is OK and just place the node in the correct bucket
> for that new id? Or do i dump that node from the routing table? Do i ban
> that ip/port combination?

My implementation simply drops such *replys*.
Inserting the node into a new bucket may make sense but in 'real-world'
the new node ID likely has a longer distance and such buckets are
almost always full anyway...

I wouldn't blacklist the node: Otherwise it would be hard for
dynip users (almost 100%) to get into the network.

> So the question is do we code for what the vaguely written spec says or what the mainline
> implementation does?

My implementation behaves like mainline: Accepting INTs and Strings.
But i do not accept lists/dicts for 't'.

> There are implementations out there that truncate to single chars and others that expand the value to
> anywhere between 2 and 8 chars.

Very ugly :-)

> There's no reason why sha1-hash is any better than a random int,

hashing a secret token with the IP does use less memory.

> considering that mainline appears to accept anything, and it did leave the
> actual implementation of the token undefined, i think it should be defined
> as being any bencoded value. This would make things consistent with the
> transaction id's.

Accepting any int/string is fine, but i don't see a reason to accept


More information about the BitTorrent mailing list