W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] Throw error if data channel's buffer is filled, rather than closing.

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Wed, 14 Jun 2017 20:57:26 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-308555964-1497473844-sysbot+gh@w3.org>
> - When there are already buffers queued, it should attempt to queue the buffer without attempting to send to underlying data transport.

Good catch... Reworded to make this clear.

> - If there is error sending to underlying transport, should there be error thrown? Or should the interaction with underlying transport be asynchronous and queued as a task?

It should always be asynchronous. That way the application only has one thing to listen to for SCTP protocol level errors: `onerror`.

> - If readyState is `closing` or `closed`, why is that error ignored while others are thrown?

I don't see how `send` could work if `readyState` is `"closing"` or `"closed"`. I changed the `readyState != "opening"` check to `readyState == "open"`.

GitHub Notification of comment by taylor-b
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1209#issuecomment-308555964 using your GitHub account
Received on Wednesday, 14 June 2017 20:57:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:39 UTC