[bittorrent] DHT - Clarifying the spec

Alan McGovern alan.mcgovern at gmail.com
Sat Mar 3 08:30:25 EST 2007


Ah, now i understand. That sounds reasonable enough.

Also, I'm planning on adding an extra DHT page to wiki.theory.org which will
contain these clarifications to (hopefully) make it easier for people to
understand how to implement DHT. When i get that done, i'll post the link
here so people can check it out and add any extra detail they feel
necessary.

Thanks,
Alan.

On 3/3/07, Ludvig Strigeus <strigeus at gmail.com> wrote:
>
> Let me clarify a little.
>
> For transactions, it allows incoming strings with a length of 0-16. Any
> other packets are dropped. It sends out transactions as strings that are 4
> byte long.
>
> If an incoming token is not a string with a length of 0-20, it's an error.
> Tokens are sent out as 20 byte long strings.
>
> /Ludvig
>
> On 3/3/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> >
> > Hi,
> >
> > 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?
> >
> > Thanks,
> > Alan
> >
> > 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/046feac9/attachment.html 


More information about the BitTorrent mailing list