As ianlevesque mentioned in the link below, http://peerjs.com/status is a good overview of current state of data channels. As Firefox stabilizes their WebRTC data channel support, I will implement it. Hopefully there will soon be cross-browser support as well for data channels.
Firefox is currently ahead on the data channel, right? They support sending blobs / arrayBuffers directly, while Chrome doesn't yet have a reliable transport or binary data support.
Your example translates the file into a base64 string to send over the unreliable channel, which ends up being a pretty big performance hit compared to a native binary transport.
All of this is to say: WebRTC is getting there, but it's still going to be several months before it's ready for more than demos like this.
It's true that it supports binary / reliable transport already but there are some very annoying not-to-spec issues. As a library developer, if I added code to support it, it would just go to waste because in BugZilla they've already patched but not pushed changes to these issues.
Depending on how they're writing their files; firefox doesn't support persistent file storage last time I checked.
Firefox does have indexeddb, but if you want to do seek operations you're out of luck.
EDIT: To explain more, without seek writing dealing with large files is incredibly expensive, you have to write everything you've got to indexeddb every time you want to modify it.
This is neat. I've been meaning to do something like it myself for fun. I'd be far more interested in one that just let's you drop a file and gives you a URL for your friend to visit with no other steps. Having one of these services that does the transfer directly peer to peer without accounts or setup steps would be great.
P2P doesnt really work with URLs though as you need to be online for the recieving end to get your file. Some traditional filesharing/upload site would work better in that case imo.
For a P2P scenario it makes sense to have something like a chatroom.
Warning:
-Data is transmitted here without encryption, directly to the other users in this WebRTC room. Use caution if sending sensitive files and communicate file passwords through a more secure channel.
When I was initially developing this a month ago, I used the Chromium nightly build on Ubuntu on my laptop. Since then my laptop's video card died. I'm going to probably roll out a linux VM soon to make sure this works with Chromium nightly still.
One of the coolest implementations of WebRTC is a project my friend launched called PeerCDN (https://peercdn.com/) - basically allows you to reduce bandwidth costs by leveraging the resources of active users on your app.
I remember looking into the feasability of something like this about 3-4 years ago when I was working on a social game with ~10 million DAU. Our bandwidth costs for static files were really really high even with a big discount from S3 because we were a heavy user. It's awesome to see that it is finally a reality.
With things like this, getting exposure isn't a matter of having the money to host your content, but simply a matter of being popular. The more popular you are, the more likely that you can offload static file hosting to those consuming your content.
As soon as I saw the WebRTC demo I went looking through the bittorrent spec to see how that was done, to then see how I could do something similar. Looks like you beat me to it, but it's a powerful tool nonetheless. Just imagine Reddit only hosting their database and a single server for master replication.
Allows active users of your app to spy on each other, seeing who connects and when.
Or maybe DOS your site, by pretending to be a PeerCDN participant but instead sending large chunks rate limited to 0.5Kb/s. The SHA1 hash check will stop them being used, but only after a long delay. People could be having a bad experience and you wouldn't even know by watching server stats.
The feature of WebRTC is that you don't have to install any plugins or extensions, but wait, you have to install a 22MB browser instead of few KB IRC client.
43 comments
[ 4.7 ms ] story [ 94.4 ms ] threadhttp://www.webrtc.org/firefox
Your example translates the file into a base64 string to send over the unreliable channel, which ends up being a pretty big performance hit compared to a native binary transport.
All of this is to say: WebRTC is getting there, but it's still going to be several months before it's ready for more than demos like this.
I wish developers would honestly stop doing that already. Capabilities and stability are far more important than a logo.
Firefox does have indexeddb, but if you want to do seek operations you're out of luck.
EDIT: To explain more, without seek writing dealing with large files is incredibly expensive, you have to write everything you've got to indexeddb every time you want to modify it.
For a P2P scenario it makes sense to have something like a chatroom.
I hope webrtc does better with NAT.
http://i.downloadsquad.switched.com/2011/03/23/sendoid-offer...
http://rtccopy.com/#KJMHud6Q
Edit: Incase anyone is interested, I have a chat log up: http://ancarda.net/rtccopy.log.txt
My girlfriend brought up a good point: is there any way to opt-out of seeding?
With things like this, getting exposure isn't a matter of having the money to host your content, but simply a matter of being popular. The more popular you are, the more likely that you can offload static file hosting to those consuming your content.
Or maybe DOS your site, by pretending to be a PeerCDN participant but instead sending large chunks rate limited to 0.5Kb/s. The SHA1 hash check will stop them being used, but only after a long delay. People could be having a bad experience and you wouldn't even know by watching server stats.
How is the connection between peers encrypted?
"Your browser will likely crash if you attempt to send a single file larger than 100MB, your mileage will vary."
I blogged about it back in 2009 anyhow (under the self-effacing title of "Opera is about to change the world?!"!).
http://en.wikipedia.org/wiki/Direct_Client-to-Client