This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25102 - RTCDataChannel::send() steps are not proper.
Summary: RTCDataChannel::send() steps are not proper.
Status: RESOLVED LATER
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Adam Bergkvist
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-20 04:52 UTC by Kiran
Modified: 2014-12-15 10:39 UTC (History)
4 users (show)

See Also:


Attachments

Description Kiran 2014-03-20 04:52:17 UTC
step 2: should be changed from 
2. If channel’s readyState attribute is connecting, throw an InvalidStateError exception and abort these steps.

to

2. If channel’s readyState attribute is closing or closed, throw an InvalidStateError exception and abort these steps.

If readyState attribute is new or connecting state, then step 4: "If channel’s underlying data transport is not established yet" will give sufficient support.

Since chances are there to get the readyState converted from connecting to open, during the time of buffering, it is better to follow this order.
Comment 1 Adam Bergkvist 2014-06-10 13:44:33 UTC
We imitate WebSocket here and don't throw unless the channel is connecting [1]. Calling send() on a closed DataChannel will simply increase the buffered amount since nothing is sent.

[1] http://dev.w3.org/html5/websockets/#dom-websocket-send
Comment 2 Kiran 2014-06-11 15:28:15 UTC
(In reply to Adam Bergkvist from comment #1)
> We imitate WebSocket here and don't throw unless the channel is connecting
> [1]. Calling send() on a closed DataChannel will simply increase the
> buffered amount since nothing is sent.
> 
> [1] http://dev.w3.org/html5/websockets/#dom-websocket-send

After reading the websocket spec, the following is my understanding,

1. websocket spec has not explicitly specified what whether to raise an exception or not if the connections ready state is closing or closed. But in general case, socket APIs will raise exceptions if the sockets are close.

2. It is specified that bufferedAmount attribute must be increased only if there is no exception.

"Any invocation of this method with a string argument that does not throw an exception must increase the bufferedAmount attribute by the number of bytes needed to express the argument as UTF-8"

In datachannel case, spec is specifying to abort the steps if readystate is "closing" or "closed". Generally implementations will raise any exception in this case.

So, it seems it is better to move this state prior to that of increasing the buffered amount, like.

"If channel’s readyState attribute is connecting or closing or closed, throw an InvalidStateError exception and abort these steps"
Comment 3 Adam Bergkvist 2014-06-12 05:14:58 UTC
(In reply to Kiran from comment #2)
> After reading the websocket spec, the following is my understanding,
> 
> 1. websocket spec has not explicitly specified what whether to raise an
> exception or not if the connections ready state is closing or closed. But in
> general case, socket APIs will raise exceptions if the sockets are close.

The fact the spec (WebSocket.send()) doesn't say that an exception should be raised if the readyState is closing or closed means that there must be no such exceptions at that time.

> 2. It is specified that bufferedAmount attribute must be increased only if
> there is no exception.
> 
> "Any invocation of this method with a string argument that does not throw an
> exception must increase the bufferedAmount attribute by the number of bytes
> needed to express the argument as UTF-8"

Yes. We don't have that clarifying paragraph (I think), but the DataChannel.send() algorithm specifies how bufferedAmount is increased.

> In datachannel case, spec is specifying to abort the steps if readystate is
> "closing" or "closed". Generally implementations will raise any exception in
> this case.

DataChannel.send() is imitating WebSocket.send() when it comes to exceptions so it's intentionally not raising an exception on "closing" or "closed". Sending data on a DataChannel that has closed will simply increase the bufferedAmount like WebSocket do. You will off course get notified with an event when the DataChannel closes.
Comment 4 Kiran 2014-06-12 15:54:56 UTC
We might have followed the WebSockets in some scenarios, but not in all scenarios.
There are some differences which I found between WebSockets and DataChannel. The following is one, we may find some more also. 

1. In case of WebSockets "closing" should start only after sending all the pending buffers.

"The close() method does not discard previously sent messages before starting the WebSocket closing handshake — even if, in practice, the user agent is still busy sending those messages, the handshake will only start after the messages are sent."

DataChannel.close() has not specified any information of this kind.
Perhaps this might be the reason websockets are not throwing exception for send() in 'closing' state, but I am not sure. 


In case of DataChannels, I don't find any use for incrementing bufferedAmout value after closing.
Comment 5 Harald Alvestrand 2014-10-31 16:40:37 UTC
This looks as if it needs some discussion.

A specific proposal needs to be made, and sent to the list for review.
Comment 6 Dominique Hazael-Massieux 2014-12-15 10:39:37 UTC
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues

Please subscribe to the issues you want to keep watching.