Unlike a broadcast medium the price of popularity on the web does not
scale very well. Popularity and the cost of bandwidth go hand in hand.
A popular podcast by a small or independent content creator can have
serious financial repercussions as word spreads and downloads increase.
I’m sure anyone who has encountered the Slashdot effect will concur
that being popular has hits drawbacks.

Bulging bandwidth costs is what BitTorrent
was originally designed to alleviate. By distributing content across
multiple dynamic servers bandwidth costs are shared by those who are
consuming the content and a temporary community sprouts up for each new
piece of content made public using the BitTorrent format.

At
the moment, BitTorrent is on the slightly more advanced side of web
browsing. In many cases the user must understand that they have to
download a BitTorrent client in order to receive the content or in many
cases help the producer with their bandwidth concerns. At the technical
level, a BitTorrent file is essentially treated as a separate MIME type
(application/x-bittorrent). This helps the web browser associate
BitTorrent files with the BitTorrent client.

I would argue
that BitTorrent, while technically an application, can also be viewed
as a transport mechanism on top of HTTP. The HTTP 1.1 specification, section 14.3
provides for various types of encodings when delivering content. By
providing an encoding type of “bittorrent” an HTTP client could
indicate that it supports the BitTorrent natively and provide bandwidth
savings seamlessly for the user much like the current gzip encoding
provided in most web browsers.

Now, we can argue semantics and
say that technically BitTorrent is not an encoding scheme. This may be
technically true however without modifying the HTTP specification it’s
a nice way to embed BitTorrent such that the transfer is virtually
seamless. The server transfers the necessary torrent information and
the client procures the transfer as a standard BitTorrent download. But
why not just have the client detect the application/x-bittorrent MIME
type? Unfortunately there’s no way for the server to know if the client
can handle the BitTorrent MIME type. The Accept-Encoding header lets
the client tell the server what it can support and the file is served
up appropriately.

There was some support behind the idea of baked in BitTorent on the server side with mod_torrent
but the project has been suspended due to lack of time. This echos my
current situation in that I don’t have the time at the moment to
implement such a technique but I’m interested in what’s possible.

I know that the podcasting community is grappling with bandwidth issues
and that BitTorrent has been mentioned a few times. I’m curious what
other’s thoughts are.

Popularity: unranked [?]


SPEAK / ADD YOUR COMMENT
Comments are moderated.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Return to Top

Bake in the BitTorent

FRESH / LATEST POSTS

FEATURED / BEST OF Michael Glenn’s Blog

My Road to HD
My Top 10 iPhone Apps
Rogers un-connected calls?
Flash 10 Still a Poor Performer on Macs and Linux
Please Explain AGO Policies
2.2 Podcasts - Right Order but Download Flaw
Behold the Power of the Twitter
The Developer Hat
iPhone App: Need for Speed Underground
Chest Pain at Toronto General

FOLLOW / YOUR COMMENTS

TAG / CLOUD

ago flash foursquare hohoto hospital iPhone iphone applications ipod Mac mobile osx photography podcasts rogers twitter video wireless