Throw error if data channel's buffer is filled, rather than closing. #1209
Conversation
Fixes w3c#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.
webrtc.html
Outdated
| data transport</a> <a>with an error</a>.</p> | ||
| <a>underlying data transport</a>. If the data cannot be sent, buffer | ||
| it, and if this is not possible because the buffer is full, | ||
| <a>throw</a> an <code>OperationError</code>.</p> |
There was a problem hiding this comment.
I don't know if these are the right errors; suggestions welcome.
There was a problem hiding this comment.
The WebIDL spec [1] says that InvalidAccessError is deprecated.
|
Interim topic to decide between options? And are they exclusive? |
|
They're not necessarily mutually exclusive, no. |
|
Related to Issue #1287 |
|
I think there are few clarifications needed:
|
Good catch... Reworded to make this clear.
It should always be asynchronous. That way the application only has one thing to listen to for SCTP protocol level errors:
I don't see how |
👏 LGTM. This should also fix #1376 since it is now clear than actual data transmission is done in parallel. |
webrtc.html
Outdated
| <li> | ||
| <p>Queue <var>data</var> for transmission on <var>channel</var>'s | ||
| <a>underlying data transport</a>. If queuing <var>data</var> is not | ||
| possible because no more buffer space is available, <a>throw</a> an |
|
Made a comment, but I think we can merge now (regardless to whether or not we change based on that comment). |
webrtc.html
Outdated
| data transport</a> <a>with an error</a>.</p> | ||
| <a>underlying data transport</a>. If the data cannot be sent, buffer | ||
| it, and if this is not possible because the buffer is full, | ||
| <a>throw</a> an <code>OperationError</code>.</p> |
There was a problem hiding this comment.
The WebIDL spec [1] says that InvalidAccessError is deprecated.
webrtc.html
Outdated
| <p>If the size of <var>data</var> exceeds the value of <code><a | ||
| data-link-for="RTCSctpTransport">maxMessageSize</a></code> on | ||
| <var>channel</var>'s associated <code>RTCSctpTransport</code>, | ||
| <a>throw</a> an <code>InvalidAccessError</code>.</p> |
There was a problem hiding this comment.
Perhaps we should go with an operation error here as well since InvalidAccessError is deprecated.
There was a problem hiding this comment.
Hmm. What's the new "invalid parameter" error, then?
Remove unneeded conditions. (w3c/webrtc-pc#1404) Throw an error if data channel's buffer is filled rather than implicit closing. (w3c/webrtc-pc#1209) Throw an error if len(message) > max-message-size of the remote peer (w3c/webrtc-pc#1209)
|
We have added this in Firefox 57. I'm currently writing a shim in adapter-js. Any other implementations that support this I should to be aware of (preferrably with version number)? |
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.