Greg,
We raised this as a potential issue during the API design for
WebSocket (back when it was called TCPConnection), indicating that a
separate method might be desirable that could be called after the
WebSocket was constructed and event handlers attached.
But the decision was made that a single-threaded execution environment
made a separate method unnecessary, because the execution of the
onopen handler (for example) could not preempt the execution of the
following 2 lines of JavaScript code:
var ws = new WebSocket("ws://kaazing.net/echo");
ws.onopen = function() { console.log("OPEN"); }
Therefore, by the time the open event is delivered, the onopen handler
would have already been attached.
Kind Regards,
John Fallows.
On Wed, Nov 18, 2009 at 8:00 PM, Greg Wilkins <gregw at webtide.com> wrote:
>
> Is there a race in the websocket API.
>
> When you do:
>
> var ws = new WebSocket("ws://mysite.com","myprotocol");
>
> then the spec says:
>
> Return a new WebSocket object, and continue these steps in the
> background (without blocking scripts).
>
> Establish a Web Socket connection to a host host, on port port
> (if one was specified), from origin, with the flag secure, with
> resource name as the resource name, and with protocol as the
> protocol (if it is present).
>
>
> So if the next line in the script is
>
> ws.onopen=myopenfunc;
>
> there is a race between if the onopen function will
> be assigned and if the background connection has been established?
>
> OK it is currently unlikely that the connect will happen that
> quick - however if I'm running in a rhino test environment
> or a on a browser that is multiplexing the websocket onto an
> already existing connection, then the onopen may indeed be fast.
>
> Similar races exist for onmessage and onclose. Setting onmessage
> might miss a message that is delivered quickly after the websocket
> is opened.
>
>
> regards
> _______________________________________________
> hybi mailing list
> hybi at ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
--
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.