Score Another One for BitTorrent

The problem: some Cambridge students (that's Cambridge, UK) made a Rube Goldberg contraption: you know the deal: a bird lands on a perch, which weights down a string, connected to a pulley, which raises a lever, which starts a ball rolling down a chute, and so forth.

Well, they submitted a 5.5MB video of their contraption to Slashdot. Some of you are already slapping your heads at this, I can tell. So Slashdot posts the story, and in minutes a few thousand nerds are all hammering one machine to get at One Big File. (For the impatient: BitTorrent was made to distribute One Big Files.)

Needless to say, people are aware of The Slashdot Effect. And steps have been taken by concerned citizens to mitigate its severity. There are things like the universal distributed caching network you can use just by Coralizing a link, and someone has specifically created Mirrordot to find and cache automatically the links in all Slashdot posts.

But these are just Band-Aids for bubonic plague. They all still rely on the conventional HTTP client-server model. The client-server model is inherently limited in terms of scale. BitTorrent is decidedly less so.

I, like the rest of Slashdot's readers, wanted to see this amazing Cambridge video. So, like a polite person, I did not directly click the link in the story. I instead started sifting through Slashdot's comments on the article, where some people had politely put links to the Mirrordot version, and others still had generously put the .AVI file into Coral's cache.

I like Coral, so I copied the URL given in the post into my clipboard and pasted it into my favorite HTTP go-getter, Net Transport. It downloaded 5.5KB of a 5.5MB file and then told me it would take another 63 days to fetch the rest.

Uh. Yeah. Plan B, anyone?

So I paused the Coral cache download (Damn you, conventional client-server model!) and went back to the Slashdot story looking for the torrent. Again, I copied and pasted the torrent URL into Net Transport, and it downloaded the torrent file in about four seconds. I usually put my torrents in a common directory such as "C:\Downloads\BitTorrent\", but I was in a hurry, so I left it on my Desktop. From there, I dragged it into Azureus and....

And nothing happened.

Turns out that the BitTorrent tracker was using port 9090, which is not open on my firewall. Shucks.

All right, SSH into the firewall and put a new rule in saying connections to port 9090 are OK for this one tracker IP. I run pfctl -f /etc/pf.conf and restart the torrent. Azureus gets the file in about twenty-eight seconds. I had turned my back to do something else in that time, which meant it downloaded the file so quickly that I had to double-check to assure myself everything went as planned. It was so quick that I was not convinced the computer had done everything it was supposed to do.

But, sure enough, the file is there and, because BitTorrent uses checksums, I know it is complete and correct. And I have my content in fewer than 60 seconds, as opposed to, potentially, 60 days.