yicui / bittube Goto Github PK

This work was created beteeen 2007 and 2008, when we were searching for a P2P solution with minimum intrusion to the user experience. At the time, the mainstream P2P streaming solution were desktop rich applications such as PPStreaming, PPLive, etc. But users had already spending increasing amount of time on YouTube among other web portals. So we thought there should be some light-weight approaches that deal with transportation of the videos as plain data objects, and let those websites and their Flash players worry about the rest.

Hence we created the architecture as above, the downloading stub sits on user's desktop machine and intercepts all HTTP GET requests destined to the port(s) it listens on. It then turns to the P2P world to download the requested data and wraps it in a HTTP response back to the requester, that's it. Also given the fact that BitTorrent was already the de facto standard for P2P content sharing, we decided to make our software interoperable with other programs of the BiTorrent family, hence the name BitTube.

Our first version was adapted from the Python source code of the original BitTorrent client, then we quickly realized that this doesn't fit the video streaming scenario, where you must sequentially download the video and return any downloaded piece to your player ASAP. With this regard, the sophisticated "rarest first" and "tit-for-tat" policies of BitTorrent have little relevance in our context, so we replaced it with our own C++ implementation.

BitTube runs as a single-threaded event loop. In each cycle, it relies on the select() function (we choose non-blocking) to monitor all of its connections (tracker, other peers, its own listening port for requests from the browser, etc.) for any connect/read/write action. Also in case you are the only peer online or other peers cannot send you data fast enough to sustain your streaming, you have to fall back to the HTTP server of the original content provider. It's rather easier to consider the HTTP server as a super peer which never goes offline. But a peer behaves a lot different from a server: instead of retrieving the whole chunk of video file which is slow and wasteful, we only need get distinct pieces of the file from time to time. Here we achieve this by turning on the partial-get and keep-alive of the HTTP protocol. Looking back from now, this often reminds me of the popular Node.js+Socket.io combination in today's realtime web applications.

Then in 2009, Adobe rolled out their RTMFP protocol which changed everything. This leads to the reincarnation of BitTube, which can be found here.