[bittorrent] DHT - Clarifying the spec
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