[whatwg] Issues with Web Sockets API

[Drew Wilson]

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.

-atw

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.
>
> -Darin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090626/b7f39701/attachment.htm>