There's a lot of times that I'm watching something on YouTube that's broadcast live (like presidential debates) when I wish there was a less corporate, ad infested version where it was available. I think a P2P solution for events like this would be really cool. I've seen BitTorrent live evolve over the last few years and it's really beginning to mature. It still hasn't seen a swarm at that kind of scale, though.
Are you opposed in general to people earning money by providing you streaming content you're interested in, or would you prefer to pay for it directly rather than have ads?
Opera has (had?) one built in. The difficulty is the necessity of hashing the entire file. Torrents are great for snapshots of large files.
I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.
Or perhaps it is because there is a certain stigma attached to using a technology that enables distribution of data, even when it is against the wishes of the creator of the data.
> I think one of the reasons the torrent protocol is not built-in is that it's simply more complicated and the user experience is not as good.
That's self-fulfilling - if it were built into the browser, there's no reason you'd really have to know.
(Presumably you wouldn't run into the "zero-seeders" problem if the servers acted as seeders - they're currently serving 100% of the file anyway (without torrenting), so torrenting would only reduce that.)
Note to anyone planning on using Opera's client: it's terrible, out of spec, and banned on many bittorrent sites.
I don't think the complexity and user experience issues are completely intrinsic to the protocol - BitTornado (sadly, another client that misbehaves, and hasn't been updated in 6 years) was hands-down the easiest for less techy people to use and understand. (Each download has its own window and instance of the program, making it look and feel very similar to downloading in Internet Explorer)
Why do you say the difficulty is in hashing the entire file? BitTorrent divides the files into small chunks and hashes those, so downloading lots of small files vs downloading one big one doesn't make a lot of difference
(with a few caveats - some clients support an additional hash on each file, which can save you re-downloading data if two files share a block and only one is changed, and some clients add padding data so there is only one file per block. In practice, these are both very rare)
I'm not sure it would be so much a net gain in cost savings so much as moving those costs around to the users and local ISPs who'd upstream traffic would increase. Personally I'd rather the content providers eat those costs.
I remember reading about a P2P API inside Chrome, but that may have been just an experimental mode for WebRTC at the time. Having a built-in bittorrent technology would be a big addition to browsers, especially if they intend to use the technology for broadcasts to a lot of people in the future through WebRTC.
It seems like in about 6 months or so (crystal ball reading) this will be available in chrome stable. (createDataChannel is not yet implemented even in Chromium trunk)
It's already possible to participate in BitTorrent swarms in pure javascript with only websockets and typed arrays. (https://github.com/kzahel/jstorrent) It of course requires that BitTorrent clients know how to accept websocket connections and use websocket frames to emulate raw socket data (which is not yet the case, but very well could be)
It's actually not written in the browser. It's a javascript API that interfaces with a headless local process (communicating with AJAX over 127.0.0.1. It has issues with mixed secure-content warnings, though)
I hope YouTube et al are asleep at the wheel long enough for this to take control of large scale live events away from them - the Baumgartner jump, the debates, it'd be nice to see these handled by P2P technology...
Well, maybe. In reality they really only need their hands on the control channel (whatever that is here) and can leave the bulk data delivery to peer-to-peer routing like the internet was designed for.
Bittorrent always makes me think about transfer-capped Internet connections. It feels like even wireline-based Internet connections in the USA are moving toward being transfer-capped. I don't see how Bittorrent works in that world.
It's interesting that Bram (I assume it's still Bram's show over there) has finally gone with a new streaming-optimized protocol design. We argued about it years ago.
In the comments, "streamerp2p" is discussed, which I used as the basis for a proposal for live radio station streams along with Speex, back ~2005, when bandwidth was expensive. It's still around, apparently: http://www.streamerp2p.com/
Bittorrent itself can do streaming of static content: just request the blocks in order. It can also do streaming of live content if you chunk the live content and have an out-of-band way to update the torrent you're looking for, but that's not great.
In my proposal I mention some other systems as well:
Onion Networks' Swarmstreaming (defunct and blocked)
The proposal isn't worth posting any more; all the assumptions and business cases are obsoleted.
Today, rather than use a client at all, I'd probably push for WebRTC P2P support, funding patches in all the browsers and their mobile versions, incentivize people to upgrade their browsers, host with cheap bandwidth for everyone else, and just hold on until enough of the market has upgraded.
I agree with you that WebRTC is the obvious choice when it becomes available. It's simply too hard to get people to install a client. For users to install a client, the uses for it must be compelling enough to go through the trouble of installing an application. Dropbox is one example of how people will install software because the product offers something useful enough.
It seems like live streaming client programs simply don't have the critical mass of content available to force people to go to the trouble of installing specialized software.
The web is going to be a very exciting place indeed, once the webRTCPeerConnection.createDataChannel actually works and we can use application logic to send arbitrary payloads to peers over the internet.
Can someone create a WebRTC web app in this way, so one person can broadcast to millions through P2P technology? Or would the browser vendors need to make certain API's available before they can do that?
Once arbitrary data can be sent through peer connections via a browser javascript application, then there is no reason why the BitTorrent Live protocol (or some other similar P2P streaming protocol) could not work over WebRTC.
One difficulty I see is actually getting the binary data into a <video> element. It would be in theory possible to write to the file in the HTML5 FileSystem API and point the video element to it, but that would require transmitting the stream in a way that is ameliorable to seeming like a static video on disk.
A number of things have changed since I made that post. Streaming downloads are long since supported. Peoples's net connections are much faster than they used to be. Flash can be relied on to do playback. And I've just plain figured out a whole bunch of new techniques, reworking from the ground up, to actually get latency under control.
Facetime and Skype and Hangouts are mostly for 1-1 communication or small group communication. I think the aim for this is to enable anyone to a live broadcast to as large an audience as they wish. Like justin.tv, or ustream
There is a 10 year old PeerCast that does (or was intended to do) something very similar. The only difference, which is crucial, is that BT sits on a massive userbase that they may be able to repurpose for bootstraping their project... Though Skype was in a similar position and look how well their Vienna Project is doing (it's dead).
AFAIK, the centralized server is not a strict necessity in terms of the functionality of the core protocol. It is more of a business decision to require the central server to authorize the stream (I believe each stream has a key that must be signed by the central server). This way, DMCA can be respected and liability issues are less of a concern.
