[whatwg] Issues with Web Sockets API

[Ian Hickson]

On Wed, 29 Jul 2009, Fumitoshi Ukai (éµ~\飼æ~V~Gæ~U~O) wrote:
> 
> I'm wondering why send() doesn't raise INVALID_STATE_ERR exception when 
> readyState is CLOSED and is required to queue up the data after closed. 
> What is the reason for this behavior?

So that scripts don't get unexpected exceptions randomly based on network 
weather.


> > > 8) Many HTTPS proxies only allow connecting to port 443. Do you have 
> > > the data on whether relying on existing proxies to establish 
> > > connections to arbitrary ports is practical?
> >
> > I do not. I expect most people to use direct connections over port 81 
> > or TLS over port 443, as discussed in the introduction.
> 
> You mean TLS over port 815 here, although TLS over port 443 would be 
> practical because of common firewall configuration?

No, I meant what I wrote. I don't expect most people to use port 815, 
though it is the right thing to do. Maybe on the long term 815 will get 
used more.


> > > 11) There is no way for the client to know that the connection has been
> > > closed. For example:
> > > - socket.close() is called from JavaScript;
> > > - onclose handler is invoked;
> > > - more data arrives from the server, and onmessage is dispatched (which I
> > > think is correct, and it matches what TCP does);
> > > - finally, a TCP FIN arrives, indicating that there will be no more data
> > from
> > > the server (the underlying TCP connection is in TIME_WAIT state after
> > that);
> > > - the client never learns that the server is done sending data.
> >
> > The onclose only fires once the connection has closed, which is after the
> > TCP FIN, so it happens after the last 'message' event.
> 
> so, it means we might receive message events even after we call 
> websocket.close(), until we get close event?

Yes. But that's the case anyway -- events are asynchronous, so consider 
the case of receiving two messages. Both are queued up, then eventually 
the first is dispatched. If in response to that you close the connection, 
that doesn't stop the second being dispatched, since it was already queued 
up.


> > The attribute now lets you just wait until the buffer is empty, which 
> > is more or less equivalent, I think.
> 
> Do we need to check bufferedAmount periodically by setTimeout?
> How about firing some event when buffer is empty?

If you need to send the information anyway, just send it. This is really 
only useful in the case where you're sending information that you can omit 
completely, for example, if you're sending events on an interval, in which 
case you can just avoid sending messages if there is any buffered data.

There's no point buffering the data in JS while waiting for the send 
buffer to be empty, since the buffer in JS and the send buffer are from 
the same pool of RAM.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'