A technical overview of the WebRTC Data Channel and common problems in its use. These slides accompanied a similar talk that was given in Paris as part of the WebRTC Conference Paris 2014. You can find the complete text of the presentation here: http://viblast.com/blog/2014/12/30/overview-webrtc-data-channel/.
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
The WebRTC Data Channel
1. Web RTC Data Channel
Svetlin Mladenov Nikolay Dimitrov
2. Before we start
● The spec changes
● Bugs are fixed
● Tweaks are made
Information applies to both direct WebRTC
connections and when a TURN server is used.
3. What is the Data Channel?
● A communicational pipe/channel/socket
● Not bound to a particular problem domain
● WebRTC Video | Audio | Data Channel
4. DC was there from the beginning
Initial version was:
● Based on RTP
● Limited to ~30 Kbit/s (hacked to ~1 Mbit/s)
● Only text messages
● No reliable mode of operation
● Network dependent max message size
(typically 1KB)
5. Some History
SCTP-based implementation
● Chrome 31-33, Firefox 26-27
● Traffic and congestion control build into
SCTP => no throttling
● Reliable mode of operation
● Binary messages
● Bigger messages (32K, 64K and beyond*)
6. General Characteristics
● Message oriented
o Messages bigger than 64K get fragmented but not
reassembled in Chrome
● Reliable
● Low overhead - similar to TCP
● Secure. Except for signaling.
7. Signaling and Setting-up
● Always use a secure channel
● Mind Trickled Ice
● The “negotiated” property
● Turn off OfferToReceiveAudio
8. Message size
● Chrome supports messages up to 64K in size but Firefox supports larger ones
● Firefox cannot send a message larger than 16K to Chrome but Chrome can send to Firefox
messages of up to 64K in size
16K is the fastest and most portable message size
9. Controlling the bufferedAmount
Application
Output Buffer
Application
Input BufferNetwork
● It was broken under Chrome v36 for Windows or previous
● The meaning of bufferedAmount has changed
○ It reflected the number of messages in the output queue (buffer)
○ After Chrome v37 it reflects the total number of all buffered messages
(in bytes)
● On overflow an exception was thrown
● After Chrome v37 the channel is closed
10. Keep in mind
● No way to know if a message has been
delivered
● Errors may be delayed
11. What if the receiving side crashes?
Application WebRTC Data Channel Application
12. What if the remote App hangs?
● The remote buffer overflows
● The data channel is closed
● No reliable way to detect the case
● Not a major problem in reality
Application WebRTC Data Channel loading ...
13. WebRTC Native Library
● Android and iOS support and many more
● In a subset of C++
● Google specific tools
● Rewrite of existing code may be necessary
● Node.js as the easy way?
● It’s worth it!