[whatwg] Issues with Web Sockets API
jamesr at google.com
Fri Jun 26 14:07:35 PDT 2009
sense, but if that was the case then it's not clear when the readyState
could be updated. The spec states "When the *Web Socket connection is
closed*, the readyState<http://dev.w3.org/html5/websockets/#dom-websocket-readystate>
value must be changed to
and the user agent must queue a task to fire a simple event called close at
the WebSocket <http://dev.w3.org/html5/websockets/#websocket> object." If
it would either have to either enqueue a second task to change readyState at
some point in the future or set the readyState right before dispatching the
'close' event. The latter would be much nicer to implement - but then it
does make the readyState completely useless as it would always be exactly
equivalent to the last event that was fired on a given WebSocket.
The spec seems to be also a bit undecided about error handling. The
postMessage() description says " If the connection is not established (
readyState <http://dev.w3.org/html5/websockets/#dom-websocket-readystate> is
not OPEN <http://dev.w3.org/html5/websockets/#dom-websocket-open>), it must
raise an INVALID_STATE_ERR exception." The first part implies that trying
to postMessage() when the underlying socket is disconnected requires an
exception to the thrown synchronously, but if the readyState cannot be
that a browser could not throw an exception until the readyState was
An exception for 'too much data pending' has a similar problem - there's no
way for the browser to know that there is too much data enqueued without
blocking to check with its I/O thread (or process). An asynchronous model
would be better with an error signaled by a later callback.
I think a better way to do error handling is to have an asynchronous onerror
callback or event when the browser notes that a message did not make it to
the other side.
On Fri, Jun 26, 2009 at 4:52 PM, Michael Nordman <michaeln at google.com>wrote:
> Does disconnect() attempt to flush pending messages or drop them?
> There isn't a way to determine if the WebSocket is successfully sending the
> postMessage data? For all the caller knows, its just backing up and not
> going anywhere.
> Something that might add value is an onmessagesent event that fires after a
> postMessage has put the bits on the wire.
> postMessage() may want another exception condition... 'too much data
> pending exception'... consider calling postMessage in a while(true) loop...
> at some point the system is going to have to give up queing the data if its
> not actually making its way out on the wire.
> On Fri, Jun 26, 2009 at 1:19 PM, Kelly Norton <knorton at google.com> wrote:
>> Oh and one more thing:
>> Doesn't it seem strange that disconnect() causes an onclose event to be
>> dispatched? Should the method not be close() to be consistent with open(),
>> onopen, onclose?
>> On Fri, Jun 26, 2009 at 4:14 PM, Kelly Norton <knorton at google.com> wrote:
>>> One thing about postMessage that I'm curious about. Since it has to
>>> report failure synchronously by throwing an INVALID_STATE_ERR, that seems to
>>> imply that all data must be written to a socket before returning and cannot
>>> be asynchronously delivered to an I/O thread without adding some risk of
>>> silently dropping
>>> messages. Seems like the right choice would be to allow outbound messages to drop, which would mean that developers would be forced to do their own handshaking.
>>> I'm also not sure there is good coverage of error conditions in the spec.
>>> The only methods of error notification are exceptions in postMessage and
>>> onclose. I had assumed that a WebSocket that fails to connect would invoke
>>> onclose asynchronously, but I didn't see that in the spec. Without that you
>>> don't even have the ability to know if a socket failed to establish a
>>> connection (short of readyState polling). The spec also doesn't indicate
>>> that the readyState should transition to CLOSED on connection failure.
>>> (Description of the disconnect() method is careful to mention that it closes
>>> a connection or a connection attempt, but description of when onclose is
>>> fired just mentions a connection closing). I definitely think there should
>>> be a way to receive an event if a connection fails to establish; I would
>>> hate to have to poll another readyState.
>>> On Fri, Jun 26, 2009 at 1:34 PM, Drew Wilson <atwilson at google.com>wrote:
>>>> Yes, but the "closed" state of a given WebSocket doesn't have to exactly
>>>> match the state of the underlying TCP connection, in the same way that
>>>> document.cookies doesn't exactly match the current set of cookies that the
>>>> network stack may be tracking (they can differ when HTTP responses are
>>>> received in the background while JS is executing).
>>>> So if the remote server closes the TCP connection, it generates a
>>>> "close" event which marks the WebSocket as closed. It means that you could
>>>> have a situation where you post messages to a WebSocket which aren't
>>>> received by the server because the connection is closed, but that's true
>>>> regardless due to the asynchronous nature of the networking protocol.
>>>> On Fri, Jun 26, 2009 at 9:52 AM, Darin Fisher <darin at chromium.org>wrote:
>>>>> On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson <atwilson at google.com>wrote:
>>>>>> On Fri, Jun 26, 2009 at 9:18 AM, James Robinson <jamesr at google.com>wrote:
>>>>>>> However, users can't usefully check the readyState to see if the
>>>>>>> WebSocket is still open because there are not and cannot be any
>>>>>>> synchronization guarantees about when the WebSocket may close.
>>>>>> Is this true? Based on our prior discussion surrounding cookies, it
>>>>>> seems like as a general rule we try to keep state from changing dynamically
>>>>>> while JS code is executing for exactly these reasons.
>>>>> I think this is a very different beast. The state of a network
>>>>> connection may change asynchronously whether we like it or not. Unlike
>>>>> "who" may access cookies or local storage, the state of the network
>>>>> connection is not something we solely control.
>>> If you received this communication by mistake, you are entitled to one
>>> free ice cream cone on me. Simply print out this email including all
>>> relevant SMTP headers and present them at my desk to claim your creamy
>>> treat. We'll have a laugh at my emailing incompetence, and play a game of
>>> ping pong. (offer may not be valid in all States).
>> If you received this communication by mistake, you are entitled to one
>> free ice cream cone on me. Simply print out this email including all
>> relevant SMTP headers and present them at my desk to claim your creamy
>> treat. We'll have a laugh at my emailing incompetence, and play a game of
>> ping pong. (offer may not be valid in all States).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg