[bittorrent] DHT - Clarifying the spec

Alan McGovern alan.mcgovern at gmail.com
Fri Mar 2 21:25:00 EST 2007


Also, what do people think of the version field? Is everyone willing to
implement that too? It's the DHT equivalent to putting -AZ2500- at the start
of your peerid in a bittorrent handshake to indicate you're Azureus.

Alan.

On 3/3/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
>
>
> > 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/691d9b2d/attachment.html 


More information about the BitTorrent mailing list