WebRTC communication corner cases (#7)

Feb. 27, 2015

Today I’ll offer a very brief Friday read covering some special cases of WebRTC data channel (DC) behavior - short and sweet as they say.

What if the receiving side crashes?

The first one is the case when the receiving side crashes. In this situation, the app is obviously not going to receive any messages. However, it can send messages without getting an error. The DC will eventually figure out that the other side is gone and cannot be reached and will notify the app of the error. You can guess, though, that this detection takes a long time. In real-world situations, periods of 5-10 minutes or longer until the DC finally figures out that the receiver is unreachable have been observed.

What if the remote app hangs?

The other extreme case is when the remote app hangs. The most important thing one should know in order to deal with this case is that WebRTC works in an asynchronous manner relative to the main application. That is, when a message is received, WebRTC and the DC will take the message from the network and put it on the input buffer and then notify the application. But if the application hangs or is busy doing something else then the DC simply does not care. It has done its job of receiving the message, putting it on a buffer and notifying the app. The fact that the app is unable to handle it is of no concern to the DC or WebRTC. So eventually when enough messages have been received, the input buffer will overflow and the DC will be closed. The buffers tend to be quite large, so it could take quite a long time before the buffer overflows. As I mentioned, the DC is not concerned with this problem and there is no way of detecting this case. 

In both cases, if faster detection is required, the app has to do it itself in the application layer - usually using some form of keep-alive messages.

The moral of the story is that although using WebRTC is very easy, it cannot solve all the issues. The developer should think about all the different ways the network and the communication could go awry and take them into account.

Author: Svetlin Mladenov, Chief Architect


This is the seventh article in a series on the topic of the WebRTC data channel. All posts are based on a talk our Chief Architect, Svetlin Mladenov, delivered during the WebRTC conference expo Paris 2014. The accompanying slides are available here and the entire lecture itself can be seen on our YouTube channel.

[Go to Post #1: WebRTC Data Channel: An Overview]