Calling All Broadcasters
blog.bittorrent.com
blog.bittorrent.com
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 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)
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.)
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 a problem we have in my house with Spotify, which utilises P2P to lower costs - it has a negative effect on anyone else who is gaming.
And then others could make the stream more resilient.
I installed the client in Debian and live.bittorrent.com worked well with Chrome at least.
Once I see open source clients and streamers, then I'll be really excited.
http://nasaweb.ideascale.com/a/dtd/Cut-Costs-By-Using-BitTor...
Here's Bram in 2004 arguing that live streaming is a niche market: http://bramcohen.livejournal.com/4294.html
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:
Peercast: http://web.archive.org/web/20060207013338/http://www.peercas... (defunct, Internet Archive link)
P2P-Radio: http://p2p-radio.sourceforge.net/ (defunct)
Allcast: http://web.archive.org/web/20060805040005/http://allcast.com... (defunct, Internet Archive link)
Chaincast (dead and blocked from IA)
Abacast: http://web.archive.org/web/20061017041905/http://www.abacast... (IA link, they're still around but now cloud-based)
Xiph's IceShare: http://wiki.xiph.org/IceShare (defunct)
Robert Haarman's StreamDist prototype: http://inglorion.net.nyud.net:8090/software/#streamdist
Andrew Brampton's research and prototype: http://web.archive.org/web/20100325135652/http://www.lancs.a... (IA link)
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.
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.
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.
mac/win/nix/droid. we use it around olympics/world cup time. nix client is open source, anyone know an open source server?
I don't think that's the lesson to take from BitTorrent.