How to get the first peer from a torrent-magnet link?

Question

I've been trying to understand the torrent-magnet technology, but I can't seem to figure out how you get connected to the first peer when opening a magnet link.

When you get a magnet link like below, it contains no initial peer - only the BitTorrent Info Hash (btih) and the file name.

magnet:?xt=urn:btih:bbb6db69965af769f664b6636e7914f8735141b3&dn=ubuntu-12.04-desktop-i386.iso

According to BitTorrent & Magnets: How Do They Work? (MakeUseOf)

If you click a magnet link that does not specify a tracker (tr) the first peer will be found using DHT. Once you’ve got a peer, peer exchange kicks in too.

The DHT article on Wikipedia does not specify how to find a peer, but in the Kademlia article (upon which BitTorrent DHT is based), it says

A node that would like to join the net must first go through a bootstrap process. In this phase, the joining node needs to know the IP address and port of another node—a bootstrap node (obtained from the user, or from a stored list)—that is already participating in the Kademlia network.

But where does it know that node from? I don't see an address or anything present in the magnet link. Since it's decentralized (trackerless), I wouldn't expect it to know the node in advance. Or is the DHT in fact not decentralized?

Bubalo

Answer 1

For the most part, when you start a bittorrent client, bootstrap off of:

1. nodes from your last session, that were saved to disk
2. other peers that you have on any of the swarms you're on

There are a few well-known bootstrap nodes which clients can use if they have no other means of finding any. Essentially the only case this happens is when you install a client for the first time, and the first torrent you download is a magnet link without a tracker.

You can then hit router.utorrent.com:6881. I believe transmission, azureus and bitcomet run similar routers, and possibly other clients as well.

By "router", I mean a node that appear to behave like any other node in the DHT, but probably has a different mechanism for determining which nodes to hand out, and probably is optimized specifically for the use case of just introducing dht nodes to each other.

UPDATE: you can run your own DHT bootstrap machine, here's the source code.

Jenette

Shouldn't the bootstrap node, e.g., dht.transmission.com, simply a tracker? The way I understand it is that it needs to keep track of the list of peers per info hash - which is exactly what a tracker does. – Kiefer

the bootstrap nodes are different from bittorrent trackers. They don't keep peer lists per info-hash, they keep a single node list. The DHT protocol is also different from the tracker protocol. – Jenette

router.bittorrent.com:6881 67.215.246.10 dht.transmissionbt.com:6881 212.129.33.59 87.98.162.88 2001:41d0:c:5ac:5::1 dht.aelitis.com 174.129.43.152 // Vuze router.silotis.us:6881", // IPv6 router.utorrent.com:6881 82.221.103.244 router.bitcomet.com dht.libtorrent.org:25401 // @arvidn's those are not simply a tracker. Same servers for tor, metrics.torproject.org/rs.html#search/flag:authority%20 Without them Tor or Bittorent will not work. Blocking then will not allow to stop Bittorent, since Cademlia allows discovery of intial nodes by just simple bruteforce, but still. – Frech

I don't understand what your point is. It seems these two sentences are contradictory: "Without them Tor or Bittorent will not work." and "Blocking then will not allow to stop Bittorent". Having access to a DHT router node is not necessary to bootstrap into the DHT. There are other means to find bittorrent peers, as long as you have access to at least one, you can probably bootstrap. – Jenette