15

Using my google-fu I was able to find only a few nodes:
router.bitcomet.com, router.utorrent.com, router.bittorrent.com

Is there somewhere a list of all bootstap nodes which I'm not aware of? Where do the torrent client developers get addresses of the bootstrap nodes? (I've looked at deluge source code and seen the modes above hardcoded.)

Moonwalker
  • 2,180
  • 1
  • 29
  • 48

3 Answers3

13

so far i have got these.

session = lt.session()
session.listen_on(6881, 6891)

session.add_dht_router("router.utorrent.com", 6881)
session.add_dht_router("router.bittorrent.com", 6881)
session.add_dht_router("dht.transmissionbt.com", 6881)
session.add_dht_router("router.bitcomet.com", 6881)
session.add_dht_router("dht.aelitis.com", 6881)
session.start_dht()
  • What happens if all of those go down at the same time? – paulkon Nov 13 '15 at 09:09
  • 2
    @paulkon: then your client would still have other means to find DHT nodes: a cached list of nodes from previous sessions, peers from other ongoing torrents, peers from trackers, or even nodes embedded in the `.torrent` file – MestreLion Dec 11 '15 at 05:38
7

Those are the only bootstrap servers I know of. Note that router.bittorrent.com is just an alias for router.utorrent.com.

uTorrent just uses router.utorrent.com as its bootstrap server, and I imagine most other clients do as well.

If you have a specific client you're interested in know what it bootstraps off of, you can always wireshark its DHT traffic (from a fresh install) and see where its first DHT packet is sent.

If you have any torrents, the router is not very important, since you can also bootstrap off of normal bittorrent peers.

Arvid
  • 10,915
  • 1
  • 32
  • 40
  • 1
    I'm writing specific torrent client-like application (with rasterbar libtorrent) and I want it to 1) bootstrap faster 2) bootstrap more peer in the dht table so dht searches would work faster. I thought that adding more dht bootstrap nodes would help. Is there a way to create a one myself? I've tried to google it but no luck – Moonwalker Feb 28 '12 at 04:58
  • 2
    You might want to profile where the time is spent and adjust your settings a bit. Bootstrapping faster won't necessarily make searches any faster. The size of the routing table probably won't make a significant difference, and it's sort of defined to be 8 + 8 nodes per bucket in the protocol. You can enable DHT logging and also inspect the DHT status runtime, see the last fields of session_status http://www.rasterbar.com/products/libtorrent/manual.html#status – Arvid Mar 01 '12 at 06:03
  • So in general there is no way to speed up dht searches? – Moonwalker Mar 01 '12 at 06:47
  • 1
    There is no way to make your RTT to your DHT nodes any shorter. That doesn't mean there's nothing you can optimize. Having more requests in parallel might make it faster. Making sure you're properly bootstrapped is important. looking at logs and how it behaves to make sure there are no bugs causing it to introduce unnecessary delays for instance. My point is that you probably should profile before jumping to "optimizations". – Arvid Mar 01 '12 at 23:06
4

You initialise from a well known nodes as you mentioned above, i.e. "router.bittorrent.com:6881"

Then it's up to the DHT client to keep a track of nodes from thereon in.

There is nothing stopping you from saving your routing table between sessions, though many of these nodes are likely not to be running the next day.

Since you're supposed to maintain the routing table, you may want to keep an eye on the nodes with the longest uptime and persist those between sessions.

With my own tests DHT startup (until a reply to find_node, returns your node) is pretty quick from cold start.

oPless
  • 618
  • 1
  • 8
  • 18