[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
jorlow at chromium.org
Thu Sep 3 23:06:09 PDT 2009
For the record, I'm perfectly happy with WebSockets not being made any more
complicated for v1 (i.e. no multi-plexing), but I don't think your arguments
against it are compelling at all, so I'm going to play devils advocate:
On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > What would the wire level look like?
> > It could be as simple as this: An extra byte or two at the beginning of
> > every message that says which "channel" is transmitting. A way to send
> > control messages, two of which would be used to open and close channels.
> I don't understand why we'd do that rather than just use two TCP
Latency and limits within the OS.
On Fri, Sep 4, 2009 at 2:45 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 14 Aug 2009, Jonas Sicking wrote:
> > >
> > > How do you envisage multiplexing working? It's not clear to me what we
> > > could do that would be easier to handle than just having the script
> > > manually do the multiplexing at the application layer. What would the
> > > API look like? What would the wire level look like?
> > Some advantages of putting it in the protocol:
> > 1. More likely the UA implementors will make the effort of implementing
> > multiplexing (and doing so correctly), than that website authors will.
> The authors still have to implement it on the server side, though.
You could have it be an optional feature. Most websites are hosted through
just a couple servers like how most websites are viewed in just a couple
browsers. Its not like every web developer would have to implement their
own server. I don't understand why you think this server side argument is
> 3. Scripts in different tabs, and even from different sites, that
> > connect to the same server would be able to share TCP/IP channel.
> Do we really want two different pages sharing the same TCP connection?
Once again yes, for latency reasons.
> That seems like a disaster waiting to happen -- it just takes one minor
> bug on the server for information to end up in the wrong channel.
You could say the same thing about so many parts of the networking stack.
An off by one error here or there could easily mis-route a message to the
wrong app/router/etc. But they generally don't. When there are worries
about correctness, you make test suites. I really don't understand why you
think this is so risky.
> Seems reasonable, though I am skeptical about throwing this level of
> complexity at Web authors, and I don't really know how we would expose it
> at the API level.
Why is this necessary? It seems like when you open multiple WebSocket
connections to the same server, they could transparently share the same
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg