Section 11.3: RTCDataChannel: Promise send #111

Closed
aboba opened this Issue Jun 25, 2014 · 4 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Jun 25, 2014

Section 11.3 of the current editor's draft has:

partial interface RTCDataChannel : EventTarget {
Promise send (DOMString data);
Promise send (Blob data);
Promise send (ArrayBuffer data);
Promise send (ArrayBufferView data);
}

There is a known bug where send can block for substantial time. However, if this bug is fixed, It is not clear that a Promise is needed. Can we remove this?

@martinthomson
Member

What do you do when your peer's receive window is closed? Wouldn't it be nice to learn when the packets were committed to the network? (Or is this a promise that is fulfilled when the packets are acknowledged?)

@robin-raymond
Contributor

We had used promise for the sake of delivery verification (as well as better 'write driven' streaming) but the issue is that this deficiency in DataChannel is not our "problem" to fix. Justin pointed out that we should request that the original Data Channel spec writers to fix the problem in WebRTC and then we adopt the fix instead of possibly forking our own solution to the problem which might be different than there solution...

@martinthomson
Member

The problem with using acknowledgements is that it encourages a lock-step approach, which is grossly inefficient. Fulfilling the promise when the bytes have hit the network is probably useful information, because then you don't end up with a backlog of unsent messages.

I can appreciate Justin's concern here, and think that we do need to fix the API elsewhere as well. Perhaps this can be categorized with the bugs that ORTC is going to let someone else handle.

@aboba
Contributor
aboba commented Jun 25, 2014

Agree that this probably should be classified as a "WebRTC 1.0 synchronization issue", with Section 11 (Data Channel) synchronizing with whatever ends up in WebRTC 1.0.

@robin-raymond robin-raymond added the 1.1 label Jun 28, 2014
@aboba aboba closed this Jul 8, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014
Robin Raymond Added section on WebRTC 1.0 compatibility issues, responding to Issue #…
…66

Added Identity support, as described in Issue #78
Reworked getStats method, as described in Issue #85
Removed ICE restart method described in Issue #93
Addressed CNAME and synchronization context issues described in Issue #94
Fixed WebIDL issues noted in Issue #97
Addressed NITs described in Issue #99
DTLS transport issues fixed as described in Issue #100
ICE transport issues fixed as described in Issue #101
ICE transport controller fixes made as described in Issue #102
Sender and Receiver object fixes made as described in Issue #103
Fixed RTCRtpEncodingParameter default issues described in Issue #104
Fixed 'Big Picture' issues descibed in Issue #105
Fixed RTCRtpParameter default issues described in Issue #106
Added a multi-stream capability, as noted in Issue #108
Removed quality scalability capabilities and parameters, as described in Issue #109
Added scalability examples as requested in Issue #110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue #111
Removed header extensions from RTCRtpCodecParameters as described in Issue #113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue #114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue #116
Added layering diagrams as requested in Issue #117
Added a typedef for payload type, as described in Issue #118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue #121
Added explanation of Voice Activity Detection (VAD), responding to Issue #129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue #130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue #131
Addressed ICE terminology issues, as described in Issue #132
Separated references into Normative and Informative, as noted in Issue #133
6f8216a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment