[bittorrent] DHT - Clarifying the spec

Alan McGovern alan.mcgovern at gmail.com
Fri Mar 2 21:22:31 EST 2007


> > 2) Replacement nodes
> > I propose that at most 2 nodes be kept in the cache.


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.



> > 3) Different NodeID's in the response
> > If you send a message to a node and the response contains a differnt
> nodeid
> > to the one you were expecting, you should accept the new nodeid as being
> the
> > correct one and update your reference to that nodeid.
>
> Disagreed: Kademlia prefers 'old/stable' nodes to make it
> harder to 'hijack' an hack.
>
> If a node just happened to change its own ID, we should ignore the reply
> and *remove* the node from our own routing table.
> (Because we know that the old ID is dead anyway...)


What i'm asking is this: Suppose NodeA has nodeid 12345 and i've stored it
in my routing table. Then NodeA has an unexpected reboot, but goes back
online within a short period of time. That node will then have a new nodeid
(for example 54321). Now, if i send that node a message, it will respond
with the ID 54321 whereas i'm expecting 12345.

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?


> 6) Sending node information
> > You should never send a nodes information as part of a FindNode response
> or
> > GetPeers response unless you have verified that the node is good. It
> must
> > have responded to at least 1 message in the past and should also pass
> the
> > criteria in the spec for being classified as "good".
>
> Yes. This filters out firewalled peers. Sadly not all DHT clients are
> doing this :-(


This wasn't explicitly stated anywhere and i think it's an important enough
point to explicitly state.

> 7) Transaction IDs
> > Under no circumstances should the transaction id be truncated or
> > expanded or converted from a bencoded number to bencoded string or vice
> > versa.


>From my experiences there are implementations out there that can't even
handle single character bencoded strings. Those are completely broken
implementations. Now, mainline supports both bencoded strings and bencoded
numbers as valid transaction id's. In the code examples there are packets
which have the transaction id as being a bencoded number. So the question is
do we code for what the vaguely written spec says or what the mainline
implementation does? The safest thing to do (in my opinion) is to accept any
valid bencoded value and just return it as is. There are implementations out
there that truncate to single chars and others that expand the value to
anywhere between 2 and 8 chars.


> 8) Token's
> > Tokens are similar to transaction id's. They should be treated as a
> value
> > that should be returned exactly as is to the original sender. They
> should
> > not be truncated, expanded or converted to a different bencoded type.
> You
> > should assume that a token can be any of the bencoded types.
>
> I think a token should always be a string.
> Using the sha1-hash-method (as mainline does) makes sense.


There's no reason why sha1-hash is any better than a random int, and
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.



What makes you think this is a better scheme than the one outlined in the
> paper?
>
> One optimization that at least uTorrent does is that it has two timeouts
> on DHT
> messages. If a node doesn't respond within the first (short) timeout, the
> branch factor is increased by one (temporarily), and when it finally times
> out
> (with the longer timeout) OR responds, the branch factor is decreased by
> one.


Where are the timeouts listed in either the bittorrent protocol or the
kademlia paper? I'm not seeing them. The only timeouts i've come across is
the 24 hour timeout mentioned in the kademlia paper and the 15 min timeout
for nodes mentioned in the bittorrent spec. It is quite possible i'm just
missing the relevant passage though :p


Hope that helps,
Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070303/f1d2d7eb/attachment.html 


More information about the BitTorrent mailing list