Router.bittorrent.com

[Brian Scarano]

IfI have a torrent w/o any trackers in it, and I just started a bittorent client so I have no peers yet...how do I know who to first connect with in the DHT? It seems like I would have to know at least ONE node in the DHT to get started....

When a BitTorrent client connects to DHT, there is an initial place that it goes to find peers. With the original BitTorrent client, there was a url to bitorrent.com that would help get things started. I tried looking up the reference but I couldn't find it. Once you've established connections with other clients, then you can do an announce on the DHT network to find peers for the torrent you're looking for.

A trackerless torrent dictionary does not have an "announce" key. Instead, a trackerless torrent has a "nodes" key. This key should be set to the K closest nodes in the torrent generating client's routing table. Alternatively, the key could be set to a known good node such as one operated by the person generating the torrent. Please do not automatically add "router.bittorrent.com" to torrent files or automatically add this node to clients routing tables.

A client can learn about other DHT-capable peers through it's interactions with them. A peer's support for DHT is advertised in it's Handshake. Once a client discovers at least one good, well-connected DHT peer, it can navigate the DHT to find more and closer DHT peers. It will remember these peers, called nodes in DHT-speak, between restarts of the software and maintain/update the list continuously while it is running. In the worse case where a client knows of no good DHT-capable peers, it will require you to download a tracker-based torrent so it can hopefully contact a few good DHT-capable peers it learns about through the tracker.

Update:For it's initial list of DHT peers, as @Seppo points out, a torrent client can use one or more hard-coded DNS names to find the addresses for well-known peers, and it may also include a hard-coded list of peers as a final fallback as well. One limitation of DNS, however, it no port information is provided so a default port of 6881 is generally assumed whereas other means support peers operating on different ports.

The DHT bootstrapper has some interesting properties. Up until 5 years ago or so, ``router.bittorrent.com`` was running just another DHT node, just like the one in Torrent. This had some obvious problems. Since the default routing table size is 8 nodes per bucket, half of all requests to the bootstrap would get the same 8 nodes handed back to it. At several thousand requests per second, this would effectively DDoS any poor node that happened to end up in its routing table.

We rewrote the bootstrap server to have a flat array of nodes instead and to have two cursors, one for reading and one for writing new nodes into it. Every node that pings the bootstrap server is put in a queue and pulled out 15 minutes later to be pinged. If it is still alive, it is added to the node list.

The new bootstrap server will still serve nodes with invalid node IDs (in fact, legitimate nodes just joining are not likely to know their external IP yet). However, it will not ping nor add these nodes to the node list for handing out.

Hi, everyone. We have a small subnet and I installed some tracker engine for transfering files. The point is that we want to use some ratio system so we distribute only private torrents. But I founded one strange thing: once I downloaded torrent file, added it to my uTorrent client. Tracker said: 0 seeders, 0 peers. But then some peers came from somewhere (remember - torrent was private, so DHT and PEX was disabled) and I downloaded target file successfully. It was really strange... Later I found an article about how DHT works. There was information about bootstrap servers on router.utorrent.com and router.bittorrent.com, and I understood that I got my "strange" peers by DHT.

But what if I want to set limit of peers relative to uesr's ratio? And how private trackers with such ratio systems exist if everyone still can download private torrent using DHT? Where is the solution?

All theese peers had "I" flag. Thus those connections were incoming. Does it mean that it is normal situation: when I use secure (private) torrent, client allow to connect incoming peers? Can I do something with it?

But... I registered on a one of the largest russian tracker torrents.ru and tried to test private torrents here. The result is that I can't download private torrents if I have no peers from tracker (i.e. using DHT only) . Why? There are a lot of users here, much more than in out net.

The standard tracker, announces random sources and that is causing a lot of traffic (over the WAN).To prevent this I have to create individual trackers on each location. DHT would be great in this situation.

If the utorrent client cannot connect to router.utorrent.com the DHT protocol doesn't seem to work anymore. When I open a trackerless torrent it never finds it's source (even when I reroute router.utorrent.com)

It is possible for individual torrent files to include additional DHT bootstrap nodes which can then be used instead of the defaults (if the defaults are down). I pushed for this capability early in DHT support in uT.

Kind of a dumb question but since it connects to a DNS entry (router.utorrent.com), can't you just use your OS's HOSTS file to re-route router.utorrent.com to your own server's IP? Or is that what you meant above?

The problem with the second option is that I do not how I get the adresses injected from reliable nodes. The 'bootstrap client' that I was plan to use, is constantly trying to connect to the 'outside world' and DHT is failing to pick up local addresses.

Yes, this is an ancient topic but I am bumping it because I still wonder myself why the hell someone just don't invent a really trackersless system? I mean scanning the network for a purpose of finding bootstrap nodes is not that impossible. Or is?

What I'm talking about here is a "central" hub without which you can't do nothing to find peers. And in that sense, DHT network is still not trackerless. No matter what are the protocols, I'm not talking about protocols, but about the network logic. Of course I'm thinking here of "tracker" in some wider sense.

That, and Torrent will also use any peers you find through any source to gain entry into the DHT network, assuming it hasn't already done so through the router. The DHT network does NOT have a single point of failure, and the router is not a tracker.

So you say I get myself a trackerless .torrent, and if router.utorrent.com and router.bittorrent.com doesn't work, I can still obtain a list of peers and download? I don't believe that's the case. Or will someone finally open my eyes and explain how it's possible, seems like I am uninformed.

BitTorrent uses a "distributed sloppy hash table" (DHT) for storingpeer contact information for "trackerless" torrents. In effect, eachpeer becomes a tracker. The protocol is based on Kademila [1] and isimplemented over UDP.

Please note the terminology used in this document to avoidconfusion. A "peer" is a client/server listening on a TCP port thatimplements the BitTorrent protocol. A "node" is a client/serverlistening on a UDP port implementing the distributed hash tableprotocol. The DHT is composed of nodes and stores the location ofpeers. BitTorrent clients include a DHT node, which is used to contactother nodes in the DHT to get the location of peers to download fromusing the BitTorrent protocol.

Each node has a globally unique identifier known as the "node ID."Node IDs are chosen at random from the same 160-bit space asBitTorrent infohashes [2]. A "distance metric" is used tocompare two node IDs or a node ID and an infohash for "closeness."Nodes must maintain a routing table containing the contact informationfor a small number of other nodes. The routing table becomes moredetailed as IDs get closer to the node's own ID. Nodes know about manyother nodes in the DHT that have IDs that are "close" to their own buthave only a handful of contacts with IDs that are very far away fromtheir own.

When a node wants to find peers for a torrent, it uses the distancemetric to compare the infohash of the torrent with the IDs of thenodes in its own routing table. It then contacts the nodes it knowsabout with IDs closest to the infohash and asks them for the contactinformation of peers currently downloading the torrent. If a contactednode knows about peers for the torrent, the peer contact informationis returned with the response. Otherwise, the contacted node mustrespond with the contact information of the nodes in its routing tablethat are closest to the infohash of the torrent. The original nodeiteratively queries nodes that are closer to the target infohash untilit cannot find any closer nodes. After the search is exhausted, theclient then inserts the peer contact information for itself onto theresponding nodes with IDs closest to the infohash of the torrent.

The return value for a query for peers includes an opaque value knownas the "token." For a node to announce that its controlling peer isdownloading a torrent, it must present the token received from thesame queried node in a recent query for peers. When a node attempts to"announce" a torrent, the queried node checks the token against thequerying node's IP address. This is to prevent malicious hosts fromsigning up other hosts for torrents. Since the token is merelyreturned by the querying node to the same node it received the tokenfrom, the implementation is not defined. Tokens must be accepted for areasonable amount of time after they have been distributed. TheBitTorrent implementation uses the SHA1 hash of the IP addressconcatenated onto a secret that changes every five minutes and tokensup to ten minutes old are accepted.

3a8082e126