DataChannel closes unexpectedly, and without reason

[UnsungHero97]

I'm experiencing some issues with transferring files using PeerJS... the transfer is chugging along just fine, and then PeerJS just closes the DataChannel, and there's no log of what went wrong. I've turned on debugging for PeerJS, and I'm running PeerServer locally so that I can get debugging logs.

PeerJS logs in Chrome's console:

... the transfer is going well, and then the "DataChannel closed for: abc123_f9pes" line is logged, the connection dies, and the transfer dies.

PeerServer logs in the terminal:

... transfer is going well, and then the 2 "Socket closed" lines are logged, followed by the death of the transfer.

My first question is, why are the "Added ICE candidate for" and "Received ICE candidates for" lines logged several times by PeerJS, and the "CANDIDATE from" lines by PeerServer?

My other question is, why is the connection being killed? It just seems like the socket is being closed... any ideas as to what might be going wrong?

Here's an overview of my environment:

• PeerJS v0.3.13
• PeerServer v0.2.8
• Chrome v41
• Mac OS X v10.10.2

p.s. this problem persists even when running against the cloud hosted PeerServer.

[UnsungHero97]

It turns out that I was reading the file too fast, and the WebRTC data channel buffer filled up, which has a limit of 16 megabytes:

http://viblast.com/blog/2015/2/25/webrtc-bufferedamount/

If a lot of messages are sent together, they could not possibly be transmitted all at once. They are put in the input buffer. But the buffer cannot grow infinitely; it usually has some pre-determined limit. If the limit is exceeded then in Chrome >= 37 the data channel is closed, all messages discarded, and an exception is thrown. However in Chrome <= 36, only an exception is thrown. So this is an API-breaking change that was made in Chrome 37. Developers should be careful with this change if they are dealing with old browsers.

[MaxYari]

Oh my god... I encountered exact same problem, with peerJS also and i was unable to find any answer (i had assumption that its some kind-of-buffer related thing), Thank you for an idea finally, i hope this will solve my issue. It is interesting that peerJS have inner mechanism of buffering, which, as i understand, was made right for this problem, HOWEVER the it's implemented seems to rely on catching exception from unable to send, and if in new chrome chunnel is just killed, this system is now redundant. I will make an issue here about it, as soon (if) i will be sure that this is the reason.

Edit: yup looks legit, bufferedAmount goes to around 16mb and everything fails.

[UnsungHero97]

Yes, this was a painful bug to uncover. It took me days to finally understand what was happening. PeerJS needs to be updated to properly handle when the data channel buffer overflows, and Chrome kills the connection.

[MaxYari]

By the way, if someone will stumble upon this, i opened an issue and posted there a tiny edit to peer.js source to fix that #291

[afomer]

@UnsungHero97

If a lot of messages are sent together, they could not possibly be transmitted all at once. They are put in the input buffer. But the buffer cannot grow infinitely; it usually has some pre-determined limit. If the limit is exceeded then in Chrome >= 37 the data channel is closed, all messages discarded, and an exception is thrown. However in Chrome <= 36, only an exception is thrown. So this is an API-breaking change that was made in Chrome 37. Developers should be careful with this change if they are dealing with old browsers.

Small correction: 16 KB, not 16 MB, for future reference. I faced the same issue. Firefox limit is 16kiB (https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels#Understanding_message_size_limits) around the same.