Re: [hybi] Proposed way forward for WebSockets

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Tue, Jul 27, 2010 at 9:08 AM, Jamie Lokier <[e-mail]> wrote:

> On 27/07/2010, at 10:56 AM, Ian Hickson wrote:
> > Here's a proposed timeline for adding these features:
>
> Hurrah! I'm in broad agreement with this proposal.
>
> > - We fix any critical bugs (not feature additions) in the protocol as it
> >  stands today (next 4 weeks).
>
> > - We deploy the protocol in four or more major browser vendors (next 4
> >  months).
>
> [stuff]
>
> > - We add built-in support for the features that are needed based on
> >  implementation experience (about 6 months from now), including
> >  compression, multiplexing, per-frame metadata annotation, etc, as
> >  needed.
>
> Critical issue:
>
> After the first deployment wave, how can client WebSocket
> implementations request features without breaking the existing
> services that *reject* and *close* connections with additional state
> in the headers?
>
> The subprotocol field (as is) cannot be used for this by a WebSocket
> API implementation because it is not allowed to change what the script
> provides.
>
> Imho a robust, extensible negotiation slot must be present early for
> this plan to work.  Assuming this is agreeable as a requirement we can
> work on making it simple, robust, and secure.
>
> > There are a number of ways that we can make the protocol also support
> > other goals:
> >
> > - Compression of frame data
> > - Sending and receiving binary data
> > - Allowing messages to be annotated with metadata*
> > - Allowing multiple JavaScript applications from the same browser to
> >  share a connection to a server (multiplexing)*
> >
> > All of these could be supported by future backwards-compatible changes to
> > the protocol, by having the client advertise support for each feature in
> > the handshake, and having the server opt-in to using that feature. None
> of
> > these changes require fundamental changes to the handshake.
> >
> > Two of these, marked with an asterisk above, can also be implemented by
> > script; therefore a good way of determining if they are truly needed is
> to
> > deploy the protocol as is, and to see if people work around the lack of
> > that feature by implementing it themselves. If they do, then the feature
> > is needed and we should add it.
>
> I wholeheartedly support the notion that scripts could implement
> protocol features that the browser doesn't perform natively - where
> possible.
>
> I'd like to remove one of your asterisks:
>
> Useful connection sharing *cannot* be implemented in script:
>
> - How do you share a connection among multiple tabs?
> - How do you report the message events back to each tab?
> - How do you avoid blocking all tabs communications when a single tab
>  has a full event queue and is too busy to empty it?
>
> Browser security makes it somewhere between very difficult and
> impossible, depending on what browser quirks you take advantage of.
> This is already a problem today, using long-get HTTP.
>
> Connection sharing in a single tab is of course possible, but
> that also has limitations.
>
> It is conceivable to script a replacement WebSocket object type which
> "emulates" it on top of the real one while sharing conenctions in a
> single tab.  It would be good to determine if that's practicable.  I
> imagine it'll behave too different from the real one to be a drop-in
> replacement because of browser script limitations.
>
> Negotiation faces the same problem as described earlier for the
> WebSocket API implementation itself - namely that the subprotocol
> field can't be used.
>
> The solution is the same as earlier - with the addition that scripts
> need to be able to participate in negotation by requesting features
> (and somehow getting involved at the frame type level?) - which means
> an additional API function.
>
> > The other two features are clearly needed regardless, and we should add
> > them in the near future. (Adding features piecemeal leads to more
> > compliant client-side implementations, so we should not add them now.)
>
> I'm not sure what makes compression clearly needed.  This is not an
> argument against, just that I seem to be missing something.
>
> I agree that piecemeal features is good idea, and I support that
> approach.  The framework does need to be flexible enough to accomodate
> piecemeal features for it to work out.  At the moment the handshake
> may be too rigid and prevent it working out.
>
> Although I think it's a good plan, don't assume piecemeal features
> automatically results in better client-side compliance.  It makes it
> simpler to write throwaway implementations.  That is useful, but might
> also result in *less* compliance on average with the base protocol due
> to quick and dirty implementations being good enough.  We'll see.
>
> I'm not sure what HTTP history has to say about *client*-side
> implementations in this regard.  Regarding HTTP servers, history shows
> us that the first decade was littered with buggy, non-compliant
> servers due to the ease of writing bad but good enough ones.
> Compliance increased dramatically since sophisticated fully-featured
> servers became more popular.
>
> -- Jamie


I talked with Hixie about how to achieve sharing of a connection, and while
I believe that it is possible to do it with a Shared Worker (and yes, this
would address sharing across multiple tabs), I think that there are a number
of gotchas. For one thing, there would be no good way to share a worker
across different subdomains - e.g. imagine mail.google.com, www.google.com,
wave.google.com and a few others wanted to share a single websocket so as to
reduce the number of open connections for a given user. Trying to do shared
workers would basically mean using an iframe to google.com + postmessage.
This could have negative impact on memory usage in the case that various
"clients" are consuming messages at drastically different rates (too much
data in flight == big buffers). There's also the consideration of whatever
latency gets added by having to load an iframe. So, I believe that sharing
of a single connection could be done at the application level, but I am not
certain as to the efficiency of such an approach. Especially if we add
things like compression at the protocol level, which I think we should, I
think we should give strong consideration to Multiplexing and how that would
be best achieved while not making things unnecessarily complex.

As for compression, there are a number of cases where today, via using XHR
you get compression, and if you switched to WS you would lose compression
(unless you did it at application level, where again the latency question
would come up). Think e.g. suggest on google.com where you type something
and get back a list of suggested search terms. This is something that
compresses reasonably well and an example where we would not want to lose
compression.