What is the benefit (if any) of using WebRTC over plain old web sockets? I ask because I'm currently working on a project that uses web sockets, and it's been really easy to use. Now, if there is valid reason for me to switch over, I'm all ears?
WebRTC establishes p2p connection over which you can transfer media streams or other data via the data channels provided by the API.
Using WebSockets you cannot make two browsers communicate directly without using any proxy in the middle.
So WebRTC has the following benefits:
- establish p2p connection between two browsers (not necessary required to be browsers)
- transfer media (audio/video) efficiently
- allows data streaming over UDP/TCP/SCTP (you can use one, depending on your application type - for example UDP if you're looking for performance over reliability)
And the following drawbacks:
- requires more complex architecture (for the NAT traversal procedures via ICE)
- you have no guarantee that the connection between the peers will be established (in case of symmetric NATs in front of the peers you want to connect)
This still doesn't really answer why one would use webrtc for multi-user video conferencing - without working multicast (which I still think is a given between most pairs of randomly choosen dsl subscribers, not sure if it would be an option for webrtc anyway) - you'd need to transfer N-1 bitrate up from each N participant in the multi-user conference. Not sure that's workable for ten 720p streams of reasonable quality - let alone for more participants? Clearly there are trade-offs - but do they make as much sense for multi-user conferencing? The teamspeak model of muxing streams on the server seem to make more sense?
Edit: I see this is actually addressed in the linked article[1] - basically a webrtc gateway can be used. No mention of any support for (cryptographic) authentication and of peers and encryption of streams as far as I csn tell, though. Which makes it a bit worse than chatting over ham radio...
Edit2: Apparently webrtc is "secure" by default [2] - that is the streams are encrypted with a session key - but there's no (working) way to authenticate - or prevent/detect mitm. Obviously a gateway would need access to the (plain) streams for muxing (barring some creative N-way p2p key setup and just blasting encrypted data (eg by not supporting more than one peer to transmit - but with typical latencies this would probably dictate some form of manual "passing-the-mic" moderation).
Having designed a decentralized social networking system, I have become firmly convinced that - unlike bitcoin - it actually helps to have a server for each conversstion, in order to both have efficiency in the network topology as well as much more easily implement things people har come to expect, such as fair message ordering and no client able to mess up the others in a conversation. Mental poker is possible but clients still need to trust each other. May as well designate one as a server then.
The CAP theorem is likewise addressed by partitioning all the messages by conversation. There is little need for total consistency between conversations, only within them.
If you want me to elaborate further, you have to email me because there's too much to say.
[Edit: never mind, I think I misread what you were saying - you're also advocating one "client"/participant to be on a dedicated "server" (aka daemon on a well-connected/always connected host?
Leaving the rest as it might have some value either way for those considering conference solutions and topologies...]
You're commenting on the parts about authentication? Because I don't see how setting up some dsl subscriber (or 4g mobile client) in (say) Japan is going to be very helpful in splitting two dozen 720p video streams across the global Internet for a modest multi-user video conference. Never mind the issues with the connection dropping for everyone if the designated "server" experience network (or other) issues..?
The original Planetside game from SOE bundled TeamSpeak (which is not p2p, but client-through-central-gateway/server) - but the bundled version was pretty much unusable in part because it meant one player hosted the server. Worked fine with a dedicated TeamsSpeak server (eg on a vps etc).
For many uses I can also see optional recording of conferences might be useful - but that could probaly be accommodated using a dedicated recording client (probably on a "server").
You can use TURN server in case of symmetric NATs. RTCPeerConnection can accept a list of TURN servers and fallback to them in case p2p connection cannot be established.
They aren't mutually exclusive, nor do they serve the same purpose, but there are still advantages to WebRTC over websockets for some applications.
First, I dare to say that most WebRTC apps use websockets for signaling (to initialize the p2p connection). So it makes sense to use the two different technologies together.
Second, notice that the connection is peer to peer - no video data passes through your server, which saves you bandwidth and cpu cycles. This is the coolest thing about WebRTC. Even though you have to maintain websocket (or long polling, etc) connections on your server for each user, none of the data transmitted between peers will cost you anything.
In short - WebRTC is good for somethings, other things will be fine using only websocket.
WebSockets and WebRTC are two very different protocols and have very different use cases.
WebSockets is an extension to a HTTP request that permits a bi-directional, persistent link between a client and server.
You can exchange chunked messages, reliably and in-order using TCP. Once the WebSocket is established, you have free reign over what datastream is sent.
WebRTC is an extension of RTP (a UDP based protocol) that adds a layer of safety (to both users and to network infrastructure).
The key requirement for "real-time" communications mandates that reliable and in-order delivery must be sacrificed in favour of getting low-latency data transfers.
Another benefit of WebRTC is that browser-side javascript has no control over the exact datagram being sent over the wire (called RTCWeb, all WebRTC communication is encrypted between peers using SRTP). This eliminates a whole class of UDP based attacks. The client (or intermediate proxies) must not be able to send a specially crafted UDP packet to arbitrary hosts and trigger a distributed reflection attack.
Having said that, WebRTC can be used to transport arbitrary data, you just can't send an arbitrary packet.
WebRTC is peer-to-peer - two people can transfer data between their browsers without anything hitting a 3rd party server. (You still need a server to broker connections, but that's all.)
WebRTC isn't supported on IE or Safari though, so it's kind of redundant for anything but experiments at the moment.
Not anything against this. But I don't see the part that is ~300 lines of Javascript. All I see is two minified files (which look to add up to around 300kb's of JS). And a 80 loc file.
