[whatwg] Issues with Web Sockets API
ian at hixie.ch
Wed Jul 29 01:33:18 PDT 2009
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
> > > 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
> > > 11) There is no way for the client to know that the connection has been
> > > closed. For example:
> > > - 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
> > 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg