- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 May 2017 07:48:14 +0000
- To: public-webrtc@w3.org
taylor-b has just submitted a new pull request for https://github.com/w3c/webrtc-pc: == Throw error if data channel's buffer is filled, rather than closing. == Fixes #1148. Option 2 for fixing the issue. The application doesn't need to know the buffer's size ahead of time, because filling the buffer is no longer an irrecoverable error. If it doesn't care about latency, an application could send until an exception is thrown, then wait for the "bufferedamountlow" event until it can send again, similar to a non-blocking socket. Note that this is deliberately different than how WebSockets work, because the circumstances are slightly different: with WebSockets, it was expected that applications had code to handle them being closed unexpectedly. But this isn't true of WebRTC DataChannels, because before an SCTP-level timeout can occur, the application would have done an ICE restart and repaired the problem. See https://github.com/w3c/webrtc-pc/pull/1209
Received on Friday, 12 May 2017 07:48:20 UTC