[bittorrent] Questions related to mainline DHT specs...

Patrick Moor pmoor at student.ethz.ch
Sun Aug 20 05:05:44 EDT 2006

> Is there any particular reason you pick this (couldn't you just user
> your id)?  Since it returns the K closest nodes, does it really
> matter if you flipped the bit - it never should return a values type
> of exact match, correct?
from bittorrent.org: "...containing the compact node info for the target
node __or__ the K (8) closest good nodes in its own routing table."
So my guess is, there might be implementations which only return your
own node information if you search for your exact own ID.

> Also, at one point do you decide to add someone to your routing
> table?  I was attempting to do it on every transaction, but it looks
> like one of the clients is using different ports and NodeID's for
> each query, which breaks things.  Not quite sure why it would be
> doing that, or what the developer was trying to accomplish - boy, it
> sure makes the 'v' field that uTorrent added make a whole lot of
> sense - I have no clue what clients is generating the message to be
> able to troubleshoot with a locally running one.
Yeah, the clients that use different source udp port numbers are yous
broken, imho. When it comes to annoucnes/tokens, I completely ignore
them and they are not able to announce to my client (more on that later).
I usually end up adding newly seen IP/port combinations into a queue. My
client pings every node in this queue once and if a ping response is
received, I add the node to the secondary routing table. Then, when a
node in the primary table can't be reached anymore, I subtitute it with
a node from the secondary table.

> How large do you typically let your DHT table grow, in number of
> peers and routes?  In fiddling around with it, I've seen it grow to
> about 11k nodes and 6k routes after a few hours - but the caveat to
> that is I'm not being very aggressive expiring nodes yet, and I'm not
> recombining routes (not sure if I will bother) - thoughts?
I never used my DHT implementation in a real client; I only used it for
experimenting and running a big distributed tracker node. Normaly, I
used ~2,000 primary peers and ~1,000 secondary ones. And yeah, the
expiring is indeed an important thing: you basically need to do a ping
query every 15 minutes to each peer in your routing table. So this
quickly adds up to a couple of pings per second. I'm not sure if you
want to keep too many peers in a normal dht client: I'd guess that about
400 peers should already be plenty.

> Have you ever seen a node return more than 8 values/nodes for either
> a get_peers or get_node query?  Right now I support any arbitrary
> number of returns, but I wasn't sure if it was worth much.  I can
> obviously return less (such as if I didn't have anything), but have
> you seen in practice anyone sending more?
Never looked at that, I don't care about how many they report.

> Finally, on announce, when are you typically sending that?  Would it
> be fine immediately after the get_peers, so I wouldn't necessarily
> have to track the token (since I already have to track the token I
> give them)?
As I mentioned earlier, I do not use my implementation in a client.
Therefore, I've never really done any announces, only received them.
Concerning the token: You should not issue random tokens, as you'd have
to store way to much data. The mainline client as well as my
implementation create the token deterministically based on a hash on the
client's IP and port and some random seed (the same seed for the whole
session). That way, you can verify the token of the announce messages by
only looking at the IP and port it came from. This, unfortunately, does
not work with clients choosing arbitrary outgoing port numbers. You
could just use the IP address for the hash and completely ignore the
port, but I decided to keep the port and thus ignoring announces from
these broken clients.


More information about the BitTorrent mailing list