Slashdot Mirror
Trackerless BitTorrent Beta Posted
jgarzik writes "BitTorrent development is occuring at a furious pace. At the beginning of May, an Azureus update added distributed tracker and database features. Yesterday, Bram updated BitTorrent to include support for trackerless torrents in the new BitTorrent 4.10 beta."
Essentially, the client is now also a simple tracker. You still need a torrent file, you just don't have to set up a tracker now, just open your client, like you'd normally do for Kazaa or other file sharing programs.
Here is the bittorrent.com explanation:
***
BitTorrent Goes Trackerless: Publishing with BitTorrent gets easier!
As part of our ongoing efforts to make publishing files on the Web painless and disruptively cheap, BitTorrent has released a 'trackerless' version of BitTorrent in a new release.
Suppose you bought a television station, you could broadcast your progamming to everyone in a 50 mile radius. Now suppose the population of your town tripled. How much more does it cost you to broadcast to 3 times as many people? Nothing. The same is not true of the Web. If you own a website and you publish your latest video on it, as popularity increases, so does your bandwidth bill! Sometimes by a lot! However, thanks to BitTorrent the website owner gets almost near-broadcast economics on the web by harnessing the unused upstream bandwidth of his/her users.
In prior versions of BitTorrent, publishing was a 3 step process. You would:
1. Create a ".torrent" file -- a summary of your file which you can put on your blog or website
2. Create a "tracker" for that file on your webserver so that your downloaders can find each other
3. Create a "seed" copy of your download so that your first downloader has a place to download from
Many of you have blogs and websites, but dont have the resources to set up a tracker. In the new version, we've created an optional 'trackerless' method of publication. Anyone with a website and an Internet connection can host a BitTorrent download!
While it is called trackerless, in practice it makes every client a lightweight tracker. A clever protocol, based on a Kademlia distributed hash table or "DHT", allows clients to efficiently store and retrieve contact information for peers in a torrent.
When generating a torrent, you can choose to utilize the trackerless system or a traditional dedicated tracker. A dedicated tracker allows you to collect statistics about downloads and gives you a measure of control over the reliability of downloads. The trackerless system makes no guarantees to reliability but requires no resources of the publisher. The trackerless system is not consulted when downloading a traditionally tracked torrent.
Although still in Beta release, the trackerless version of BitTorrent, and the latest production version are available at http://www.bittorrent.com/
Saskboy's blog is good. 9 out of 10 dentists agree.
Hopefully... allowing more people to post more content is one of the project's goals.
With the increase of different torrents everywhere, won't that dilute the power of BT?
No, because the uploaders for a given file consist only of the people who have previously downloaded that file. So no matter how many files are "out there", the total bandwidth available to distribute any particular file is always proportional to the number of people interested in that file.
File-A's popularity won't leech bandwidth from File-B's swarm, because File-B's swarm wasn't providing any bandwidth for File-A in the first place.
I don't care if it's 90,000 hectares. That lake was not my doing.
This is how Kademlia works:
.torrent file has a 160-bit info hash embedded in it, derived from SHA-1. Now substitute the message above for the .torrent file, and the message key for this info hash -- you are now routing .torrent files to their closest nodes. These nodes, in turn, can be the tracker. If a node knows the 160-bit info hash of a .torrent, it can find a tracker by placing this hash as the message key in a lookup message and finding the closest node, which must necessarily be the tracker.
Nodes randomly generate either 128 or 160 bit node identifiers. An identifier uniquely identifies a node on the network. Traditionally, they are computed as just the MD5 or SHA-1 hash of your IP address (this is to make it harder for clients to select exactly what identifier they want, which could help them target certain files for takedown... more on that later).
In Kademlia, the idea is that messages routed through the network are identified by a message key. This is, as well, either a 128 or 160 bit value. The goal of Kademlia, and every other DHT (Google for Chord, CAN, Pastry, etc.) is to route a message to the node whose identifier is "closest" to the message key. In Kademlia, the distance between a node identifier and another node identifier, or a node identifier and a message key, is computed by simply XORing the two and treating the result as an unsigned integer.
Each node maintains (roughly) a routing table containing nodes that match successively-longer high order bits with itself. For example, node 0100... maintains an entry to a node starting with 1..., a node starting with 00..., a node starting with 011..., and a node starting with 0101... Note that in terms of distance by XOR, the first node has a distance of 1..., the second with a distance of 01..., and so forth. Thus, nodes matching more high order bits are closer to you in the identifier space.
So if you are node 1010... and you receive a message starting with 0111... You should have some node in your routing table that differs in the highest-order bit, that is, it starts with 0... Say its node identifier starts with 0000. You route the message to that node. If you compute the XOR between your node identifier and the key, and this node's identifier and the key, you will see that this node is approximately twice as close to the key as you are.
Now this node differs in the second bit: 0000 vs 0111. In its routing table, it must have some node that matches in the first bit, and differs in the second: that is, starting with 01... If the message is routed to that node, we again cut our distance to the key by approximately 1/2. This process repeats until we find the node "closest" to the message key.
Routing in this manner takes log(N) time, and each node on the network maintains log(N) connectivity. Note that there are well-established algorithms for nodes joining and leaving the network, of which the former takes log(N) time as well.
So how does BitTorrent fit in? Here's what I'm assuming: Each
You can do other neat tricks, too, like keyword searching, load balancing, and whatnot (see eMule -- it uses the Kademlia DHT for its serverless system). Other DHTs work in a similar manner. I'm a little confused as to why everyone uses Kademlia, when there are better ones out there. (Accordian, for example, is truly state-of-the-art.)
Plenty of resources on DHTs can be found at Project Iris.
- shadowmatter