Slashdot Mirror
Snag the Red Hat 9 ISOs, via Cash or BitTorrent
Tectonic Rumblings
Every so often a new tool comes along that causes a shift from Bronze to Iron, that divides history into "before" and "after." The peer-to-peer world has certainly seen its share. Those who used 486s to encode and play MP3s remember it wasn't just abysmal modem speeds that kept people from casual trading, but the tiresome process of finding users and content; Napster freed us from that bondage, letting the computer do the heavy lifting and freeing people to do what they do best.
When the weaknesses began to show in Napster's overly centralized model, Gnutella stepped in with a distributed, decentralized network. Audiogalaxy gave us astounding variety (even the most obscure music could always be found sooner or later) and a rich sense of community that is still sorely missed. WinMX offered the ability to connect to multiple Napster-compatible networks; with the advent of multi-source downloading, Morpheus and similar programs allowed us to rise above the limitations of slow upstream (until it's hard now to find any P2P applications that don't use it); and EDonkey added the nice touch of being able to share files before they were done downloading.
So what's the next stage of P2P evolution?
Enter BitTorrent -- a "swarming, scatter and gather" file transfer protocol developed by Bram Cohen that's taking the net by storm. Even without a friendly, unified interface, BT's ability to scale in the face of overwhelming demand while minimizing the free rider problem ("leeching") has attracted a flood of new users. But as with any tool, understanding how and why it works will always make using it easier and more fun.
All technical references are taken from the BT server tutorial and the official documentation.
Let's Start with the Basics
BitTorrent is not a 'website' or a 'network', and strictly speaking is not even a program -- it's a protocol with a number of functional implementations.
Instead of jumping right into downloading, first we'll discuss how files are served. Most new BT users are familiar with going to a website and clicking on links to .torrent files, but this just provides a friendlier interface and isn't actually necessary. All you really need to serve is a public Internet machine. The "tracker" will "keep track" of who is connected and who has which pieces of the file(s) in question. Like any public Internet service, a static IP address and/or valid hostname will make it easier for people to connect to your tracker.
To start serving, you choose a file or directory to serve and run a program which generates a .torrent file. This contains a 'hash,' which serves as a checksum to ensure the file is the same on all systems, as well as the address of a tracker. A typical .torrent file is quite small, typically 5-50k in size.
The second step is to load the .torrent file into a BT client. The client asks you where to save the file, you point it at the existing and complete copy, it verifies that the file hash matches, says the download is done and sits there uploading when necessary until you cancel it.
Here's an animated graphic (.mng, currently viewable only in Mozilla) of a torrent transfer.
Getting Started
The official BT client is available for Win32, Mac OS X, as an unstable Debian package, and as Python source code.
Getting started is quite simple; the Windows installer asks no questions and provides no options, and the only behind-the-scenes addition is that Internet Explorer now launches BT when you click on links to .torrent files. (Mozilla users will need to edit Preferences, Navigator, Helper Applications and add the mime type "application/x-bittorrent", to be launched by the btdownloadprefetched executable.) You can also download .torrent files and load them locally without going through a website.
Once the .torrent has been invoked, the client will prompt you for a location to save the file to. The client then creates a file of the appropriate size containing all zeros, and connects to the tracker to get a starting list of some random subset of available peers (other users connected to the 'swarm'). BT then starts connecting to peers and downloading random chunks of the file, and begin uploading to other peers as soon as you have enough for it to bother.
Every time your client verifies another piece of the download, it tells the tracker it has a good copy of that piece. By directly utilizing each user's outgoing bandwidth, downloads can be generally be completed very quickly while minimizing the load on the original server, in effect turning the dreaded "Slashdot Effect" against itself -- the more who want to download, the more there are to upload. Sooner or later (usually sooner), the download is done, and the client continues to upload pieces to other users.
What's In It For Me?
Now your first instinct at this point might be to close the program, but you really ought to leave it open as long as possible afterward, to help seed the file into the network. But this is really a social and cultural issue which can't necessarily be addressed through technical measures; BT can enforce fairness during the transfer with its algorithms, but no software can force the user to keep the client open. Many tracker owners keep a close eye on such things, and will generally ban repeat offenders. In any event, "giving back" your bandwidth has never been easier, even for users behind firewalls or NAT (although as always, being able to avoid or go through these will make the transfers more efficient).
Alternative Clients and Other Tools
That said, there are perfectly valid reasons to want some control over the amount of bandwidth a P2P application uses, and an experimental, unofficial client (Win32, Python source) has been created to provide a friendly interface for this. BT will automatically adjust your download speed appropriately if you set a slower upload speed, but it's still an invaluable tool for some cable and DSL users whose downloads will choke and abort if they use too much upstream, or for anyone with limited upstream who wants to reserve some of it for other uses.
Currently, both the official and experimental GUI clients use a separate window for each transfer. BT++ (Win32, Python source) has made an initial attempt at combining all transfers into one window, as well as offering some other enhancements, but users report mixed results, with some saying "it works for me" and others that it's buggy to the point of unusable; still, it's one to keep an eye on. (Caveat: BT++ provides an option to automatically stop uploading when the download is completed. I believe this deliberately encourages people to do so even if there is no real need to do so, and would advise anyone using BT++ to refrain from using this option; it's unnecessary, detrimental to the BT networks, and may lead to your IP being banned as described above.)
TorrentSpy (Win32) is another useful tool that shows various statistics about your transfers, including which files of a multi-file torrent are complete. It's not meant to replace a downloading client, but to complement it.
I should add that the speed and time-to-completion numbers may not be wholly accurate, and will typically fluctuate wildly to some extent during a transfer. (After all, do you believe Windows when it tells you how long it will take to copy a file?) The "percentage completed" at least is accurate, and you may be able to get more accurate information using TorrentSpy. A new version of BT has just been released (3.2) and its reported changes include "more even and consistent download rates".
A Few Miscellaneous Points
It's quite possible to generate .torrents for files you want to serve and then advertise them on someone else's tracker. Since anyone can run a tracker, BT is more like IRC, Usenet or Direct Connect than something like Kazaa. Like Freenet, it works best if the content is highly in demand; it's also more effective on recently released stuff. One highly recommeded website is Bstark. It doesn't provide .torrents for anyone to download, but functions as a "metatracker", that is, a tracker that keeps track of trackers. If you're a statistics geek, the graphs are a lot of fun, and even for the average user it's a simple way to check what files are most in demand and most in need of someone to serve them. This is even more effective when you combine it with an alternate means of communication such as IRC or email, making it easy for users to check supply and meet demand. The .torrent file can also be distributed by any means, be it a website, IRC channel, email attachments or perhaps carrier pigeon.
Conclusion
With the 'entertainment industry' finally focusing their attention on IRC, the cantankerous and difficult granddaddy of Internet file sharing, BitTorrent has found a niche and filled it admirably. The author understandably wishes to focus upon using BT in a legal manner. As with any new invention, "the street finds its own use for technology," and BitTorrent will undoubtedly continue to be rapidly adopted for both licit and illicit use.
Given the decentralized nature of BT networks and the rapid development of new tools, it's only a matter of time before someone writes a GUI wrapper for an IRC client, web browser and all-in-one BitTorrent interface. After all, Napster did it, as do most other mainstream P2P apps like Kazaa. Like Direct Connect with its 'hubs,' there will always be multiple BT servers available, and a unified interface would not only make it easier for users to find and download content, but free them to focus on forming the social and cultural networks that are also needed. A website typically uses far too much CPU and bandwidth to handle popular traffic, but a BT tracker uses minimal bandwidth by itself. Perhaps the next-generation clients will try to automatically locate trackers, or help the user find and serve older content as well as new releases.
The late great Audiogalaxy had many strengths, but one of its most fundamental was the sense of community it encouraged. BitTorrent wisely fills a narrow set of technical requirements, leaving a great deal to human need and will. The ad hoc arrangements and customs that have so far sprouted as expressions of the will to fill these needs are often chaotic and messy -- but that's human action for you.
I remember when 8.0 came out, it was days before I could find a mirror that didn't already have too many users connected. I think it is a great idea to use p2p to to distribute it.
Red Hat must be in serious trouble if they couldn't afford the .0 to append to the 9!
"Slashdot provides free BitTorrent stress test/load analysis"
You are not the customer.
Correct me if I've got the facts wrong. But it sounds to me like a week long wait is not really long, and that this announcement in Slashdot is not really ethical ...
It would seem to me that RedHat didn't fully think out the bandwidth hit they would take. I've got a colleague (who is an RHN subscriber too) that just had all his downloads (discs 1-3) timeout. I gave up trying to start downloads this morning. I personally think, Akamai would have been a better solution.
Is it running any faster now, after 15 minutes or so? My download rates shortly after the Slashdot story went live were around 5-7 K/s. Since then it's been steadily increasing -- presumably as more and more Slashdot readers download, install and run BitTorrent, providing more clients for me to connect to. I'm now up to 25-30 K/s, which is roughly the same as my upload speed.
Now, instead of the slashdotting the RedHat FTP sites and mirrors, the BitTorrent web site (the site distributing the client) will get the onslaught of RedHatters in search of the latest version...
:-)
Alls well from my perspective, though -- I have already installed the BitTorrent client and have the new ISO's! As such, go nuts...
n2q
Beer is proof that God loves us and wants us to be happy. -- Benjamin Franklin
when the download is complete!
Bittorent works by making everyone who downloads part of the "distribution network." By leaving the client open you are making the download go faster for everyone. I suppose this is kind of a utilitatian concept, but hey.. Slashdot readers are supposed to be idealistic, right? I'll leave mine open, and hopefully you will too.
:wq
Strange that people seem to be so religious about all the details of the GPL, except when it might hurt RedHat, in which case it's okay for them to sell it like proprietary software.
Their income strategies are to pay huge amounts for the bandwidth of thousands of people downloading their .isos?
Malike Bamiyi wanted my assistance.
I find it ridiculous that the loudest linux/open source zealots in here refuse to pay to support it. Open source programmers deserve to be paid too. Put your money where your mouth is. And yes, for the record, I've paid for every version of RH since 6.x, and I even paid for Debian once. :)
Let the flames begin.
On the one hand, BitTorrent is an excellent way of reducing bandwidth for Open Source companies... if they release their files only on bittorrent, then they can get the distro out to more people & save money on bandwidth at the same time. In that regard, I think all Linux distro companies should adopt it.
On the other hand, this is a massive leak for RedHat... if BitTorrent can always be relied upon to get the ISOs the day they're released to subscribers, then there is no incentive to become a RedHat subscriber... and thus RedHat loses money.
In the future, it would be nice if BitTorrent users could wait until after the distro is released to the public before mirroring it... Yeah, then companies like RedHat still get their 1 week advance for subscribers, AND they get to not have their servers flooded on public release day.
*sigh*... I better go buy a RH9 boxed set, I feel all dirty now.
This is true. I started out with 12 hours time left, I'm now at 6 hours. I suspect over time, this number will approach 0. :)