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."
It sounds as if the .torrent files still need to be downloaded or stored somewhere. It's just the middle step of the tracker that can (optionally) be eliminated.
You mean this?
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.
I just learned about Distributed Hash Tables this past semester and thought they were really cool. On the bittorrent page linked in the blurb, it mentions the use of a DHT in order to do the join/lookup required for locating peers.
l e for more info on them and links to example DHT implementations (such as CAN, Chord, and Kademlia).
If you are interested in how it works, you can check out http://en.wikipedia.org/wiki/Distributed_hash_tab
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
They're already going after end-users. One of my buddies just got mauled by Columbia Pictures.
It really isn't trackerless. It is distributed tracking, just like Azureus already has, but just different enough to be incompatible with Azureus's protocol. Basically you have a big distributed hash table, so the entry point for a torrent is a hash key for this table.
There are actually two possible questions out of this, "Two shares with the same name, but are different files." and "Two sources of the same file, shared seprately."
.torrent file for it, then advertizes the .torrent file on his blog. Al, Bob, Cathy, Doris, Plauge, Faith, and Garth all decide to download a copy. Some because he is making it available on his blog, others because they saw a reference to it on hos blog, but decide to go to the source and download the ISO from there. The transactions that are using the .torrent file from Joe's blog are not going to be sharing transfer space with the transactions from the official torrent site.
.torrent file for it, put the iso and .torrent on my web server, and link to the .torrent in my blog. Heather downloads the .torrent as part of her collection of that ISO, likes the file, so she puts my .torrent on her server, linking it with a blog entry, then leaves her client sharing the .iso file. In this situation, both of us would be sharing the bandwidth of distributing the .iso.
Lets say you and I both recorded the latest Britney_Spears story on ET. We each grabbed from the first frame of the story as our recordings captured it, to the last frame of the story. It happens the there was a comercial break in the middle of the story, which we have each clipped out. However our clips are not identical, and if we are both capturing from an analog source, our actual files will be different. Even if we both share the file as 'ETBritneyInterview.mpeg2' our file hashes will be different, so there will be no collision.
Next up... Joe is a fan of Ubuntu Linux, and tracks down an ISO file for it. Puts it on his web server with a
Last up, I create an ISO for some new distribution of Linux, and create a trackerless
Hope that addresses your question.
-Rusty
You never know...
There still remains one big advantage that BT has over other p2p apps, and it is a big one.
Unlike more inefficent protocols, BT choose to implement basic game theory into the design. While it is not nescessary for a client to implement the tit-for-tat algorithm (see prisoner's dilemma), pretty much all do because not implementing it would make the client work less efficently in the BT network.
Other p2p networks try to reward uploading in different ways, but all those ways are far less efficent than using the basics learned from the prisoner's dilemma.
The Tracker does not decide who downloads what. It just has a list of IPs. Each client decides what it downloads but it uploads only/better to the clients that send to it faster than the others. That way uploading clients get the biggest part of the bandwidth and clients that leech only get the rest that is not needed by one of the others.
Linux is not Windows
Bittorrent isn't a "share all the files on my hard drive" system. It's a distribution system for content publishers. It will most likely never be the former because that's how you get the MPAA, RIAA, etc on your back. If you want a list of content publishers use Google.
Also the Emule has it better that it can determine that multiple names of a file are actually the same file, based on the same Hash.
There's never any danger of downloading multiple versions of the same file because you download the torrent file from the publisher's website - not the system. That torrent connects you to one or more peers, the mini-trackers, which are presumably operated by the publisher. And then it's just standard bittorrent stuff.
It's good way to publish legitimate content. It's not a good way to distribute illegal content. First of all the torrent has a record of your peer IP addresses. So, all the lawyers need to do is have the peers listed in the torrent shut down -- then the torrent is useless. Sure, you could hide for a while using zombie windows boxes as your "master" peers, that's one level of indirection. But as they become unavailable you need to distribute new torrent files with fresh peer lists. Maybe that's not a problem, but it seems like more trouble than it's worth.
If you want a share-all-my-files p2p bittorrent, try eXeem (or eXeem Lite).