This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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
(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"
(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.
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.
This looks as if it needs some discussion. A specific proposal needs to be made, and sent to the list for review.
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.