The work we are currently doing to bring streaming to our popular µTorrent freeware has the potential to bring transformational improvements to the user experience for BitTorrent users. But its not without at least a little controversy, which I’d like to discuss in this post.
Roughly speaking, the controversy falls into two different areas:
(1) “Streaming is easy”
But it is not trivial either, which is the main reason it has not happened sooner.
Our objective is to enable streaming of files distributed using popular file formats on regular BitTorrent swarms without relying on any server infrastructure and without violating any of the core rules that make the BitTorrent protocol so effective. The file will still be downloaded to your hard drive, but you will be able to play the file while it is downloading rather than waiting for the download to complete. What we’d love to eventually achieve is an experience that might be integrated seamlessly with the webtop, so that the µTorrent client can simply provide background support to a web experience which is ultimately very similar that of YouTube or Hulu, but with radically different economics. We might call it the “µTube” vision…
What’s exciting about this is not just the fact that we have technology to achieve this, but we also have a critical mass of users who will be able to accelerate this towards broad adoption.
In short – it ain’t rocket science, but its not trivial; and its novelty is mostly in its breadth of scope rather than the fact that you will be “able to stream with BitTorrent”.
(2) “Streaming will kill BitTorrent”
We play an important role trying to safeguard the development of standards around the BitTorrent protocol – a responsibility we take very seriously. There seem to be a surprisingly large number of pundits out there who seem “sure” that streaming will mess up BitTorrent. We’re actually quite certain that this is not the case. I might go on about the technical credentials of a team including the person who invented BitTorrent, or the fact that we have more to lose than anyone if we’re wrong – but that may overdo things. We deeply respect people’s right to be concerned, and interpret the main motivator of these concerns as fundamentally the popular enthusiasm for an incredible piece of technology.
Our streaming prototype is a careful balance of using BitTorrent fundamentals (like rarest-first piece selection and tit-for-tat reciprocity) but introducing a concept of priority windows (which correspond to the portion of media actually being viewed or listened to.) We restrict any download of consecutive pieces (i.e. non-BitTorrent behavior) to a tiny (about 15 second) portion of playback.
Added to the fact that everyone hits the “start” button at a different time, many files are an hour or longer in playback duration, so we’re not surprised that so far we’ve encountered no perceptible impact of streaming on swarm health.
The most important decision that we need to bake into the user experience is deciding the point at which a file is “streamable” – not all files will have enough seeding bandwidth to allow streaming, and some may be marginal. Before any broad deployment, we expect to be quite conservative in determining if and when the “play” button shows up in order to avoid any theoretical impact on less well-developed swarms. Furthermore, we expect people’s behavior will be self-selecting in most cases – if someone tries to stream from an under-developed swarm, it simply won’t work – so they’ll probably give up.
But the important message is that we are confident that it is completely viable to enable streaming in well-seeded swarms without having any adverse effect on those swarms.
What’s more, the basics of the client will change little – streaming will be an option to be used only in cases where it makes sense to the user, and µTorrent will remain “a (very) tiny BitTorrent client”.