3 ms·

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 r

by zo1 12y ago

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?

onion2k 12y ago
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.
mgechev 12y ago
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) - has more complex API
- johansch 12y ago
  Regarding NAT: does it do anything to attempt to solve this problem, or is that entirely left to the app developer?
  - mgechev 12y ago
    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.
- e12e 12y ago
  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). [1] http://blog.mgechev.com/2014/12/26/multi-user-video-conference-webrtc-angularjs-yeoman/ http://blog.mgechev.com/2014/12/26/multi-user-video-conferen... [2] http://blog.erbbysam.com/?p=149 http://blog.erbbysam.com/?p=149
  - EGreg 12y ago
    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.
    - e12e 12y ago
trey-jones 12y ago
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.
bencord0 12y ago
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.

by zo1 12y ago

onion2k 12y ago

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.

mgechev 12y ago

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) - has more complex API

johansch 12y ago
Regarding NAT: does it do anything to attempt to solve this problem, or is that entirely left to the app developer?
- mgechev 12y ago
  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.
e12e 12y ago
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). [1] http://blog.mgechev.com/2014/12/26/multi-user-video-conference-webrtc-angularjs-yeoman/ http://blog.mgechev.com/2014/12/26/multi-user-video-conferen... [2] http://blog.erbbysam.com/?p=149 http://blog.erbbysam.com/?p=149
- EGreg 12y ago
  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.
  - e12e 12y ago

trey-jones 12y ago

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.

bencord0 12y ago

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.