[bittorrent] DHT - Clarifying the spec

Alan McGovern alan.mcgovern at gmail.com
Sat Mar 3 08:07:19 EST 2007


Reject anything but strings. Use 4-byte strings for requests.

So, will we agree that they should only be bencoded strings then? That
sounds perfectly reasonable to me. The only thing is that if it were
enforced that they should be 4 bytes in length, it would pretty much
alienate every existing client. So how about we say a transaction id has to
be a bencoded string that is between 1 and 4 bytes in length (inclusive)?
Also, can we explicitly state that tokens must be a BEncodedString of length
between 1 and 20 bytes (inclusive)?

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

I can't seem to find that paragraph in either the kademlia paper or the
bittorrent page :p Where is it?

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...

So will we take it that replies from ip/port combinations which return a
different nodeid to the one that was expected should be silently ignored?

So, that leaves me with the timeout values. Can we get some hard figures for
those. I'm still unsure where exactly i need to have timeout values as i
haven't finished my own library yet. The places where it seems to matter so
far are for 'tokens', waiting for replies to queries and timing a peer out.
The spec does detailed information for when to decide when a node is dead
and for how long to accept tokens for, but when should a peer be marked for
not replying to a message? 30 seconds after sending? 1 minute after sending?
The kademlia paper says that if it fails to respond to 5 messages in a row
it should be considered dead. Is there anything else i'm missing?


On 3/3/07, Ludvig Strigeus <strigeus at gmail.com> wrote:
> Hi,
> Oh ok, I didn't notice that. I wrote the DHT code before that spec
> existed. Well my opinion still holds, but I guess the spec needs to be less
> ambiguous to be able to apply it.
> Reject anything but strings. Use 4-byte strings for requests.
> /Ludvig
> On 3/3/07, Adrian Ulrich <torrent at blinkenlights.ch> wrote:
> >
> >
> > > I don't agree at all that it's 'nice' to accept things that are
> > outside the
> > > spec. For example accepting ints even though the spec says otherwise.
> >
> > The spec says you shall use a 'single character string value'.
> > but uses INTs and Strings in the example packets:
> >
> > Int:
> > generic error = {'t':0, 'y':'e', 'e':[201, "A Generic Error Ocurred"]}
> > bencoded = d1:eli201e23:A Generic Error Ocurrede1:ti0e1:y1:ee
> >
> > String:
> >   Response = {"t":"0", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}
> >   bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t1:01:y1:re
> >
> >
> > So what does uTorrent do?
> >
> > _______________________________________________
> > BitTorrent mailing list
> > BitTorrent at lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> >
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20070303/d3c53fab/attachment.html 

More information about the BitTorrent mailing list