BitTorrent Distributed Hash Table (DHT) or Trackerless BitTorrent I

One of the more interesting extensions to the BitTorrent protocol has been the introduction of a distributed hash table implementation. As mentioned in my previous article on the basics of the BitTorrent protocol, traditionally BitTorrent relies upon a centralised “tracker” application – which runs over standard HTTP – in order to facilitate contacting peers and so on. The requirement for a centralised tracker is obviously a major barrier to fully decentralised operation, and a problem in terms of BitTorrent’s resistance to tracker outage (perhaps even caused by legal actions). In part one of this article I’m going to look a bit at the network side of BitTorrent’s DHT.

The official BitTorrent DHT specification states that the protocol is based on Kademilia. In BitTorrent, DHT is mostly separated from the original protocol. Peers listen on an additional port, using a UDP protocol, to issue network searches and so forth. The DHT protocol is known as KRPC and consists of three message types – query (“q”), response (“r”) and error (“e”). There are four queries:

  • PING
  • FIND_NODE
  • GET_PEERS
  • ANNOUNCE_PEER

Each KRPC message is formatted in B-Encode, with various key-value pairs encoded in a dictionary structure. Each node participating in the DHT has its own routing table containing contact information for nodes “near” to it (according to a mathematical ‘distance function’). This routing table is used to produce responses to queries. We will go more into details of how this works in the next article.

The TCP BitTorrent peer protocol itself has only been very slightly extended in order to take advantage of this new DHT functionality. During the handshake, peers may indicate that they support DHT. If the receiver also supports DHT, it should send a new message called PORT (id is 0×09) with the port number of its UDP DHT service, encoded as a 16-bit value. The receiver of this message will then try to send a PING message to the peer on this port, and if it gets a reply, routing table adjustments etc should take place.

Those are the very basics of BitTorrent DHT from a network perspective. I will write more about the details of the algorithms used for routing and how the consistent hashing is employed in part two.

4 comments to BitTorrent Distributed Hash Table (DHT) or Trackerless BitTorrent I

  • xnon

    hope dht support in unworkable.
    everytime, when i use rtorrent download large file(s) size(>4gigs), like a DVD movie, my openbsd must freeze

    i saw this bug report, on openbsd bug tracker(PR No.5690)

  • niallo

    Hi xnon,

    I am working on DHT support in Unworkable. I have encountered numerous limitations in the OpenBSD VM while developing the application, and have had to work around these as best as possible. Most of these do not crash the system however – although there was one bug which was fixed a few months ago. Let me know if Unworkable is able to trigger any crashes on OpenBSD.

    Thanks for your comment!

  • rOjOr

    I’m researching how bittorrent DHT works and came across your article via a google search . It’s a nicely written explanation at about the level of understanding I’ve gained so far. I’m eagerly awaiting the elaboration promised in “part two”.

  • click170

    Very informative article, I can’t wait for your promised elaboration!
    How much longer do we have to wait?
    :)

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">