[whatwg] Feature requests in WebSocket

[Ian Hickson]

On Fri, 4 Sep 2009, Jeremy Orlow wrote:
> 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 
> > connections.
> 
> Latency and limits within the OS.

I don't see how we could hit limits within the OS with Web Sockets.

Latency could be a reason to have built-in multiplexing, but it's probably 
easier for the author to just do it manually, frankly.


> 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. 
> > >
> > > 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.

Like, the server could send back a flag saying "oh by the way I support 
multiplexing"? Yeah, I guess that could work. Might be a good way to 
extend the protocol to support this in the future -- a good forward 
migration path. The server would include a flag in the handshake, and the 
client would then know that it could send an 0x02 packet or something when 
it wanted to add a new connection... hm, that might be a little messy.


> > > 3. Scripts in different tabs, and even from different sites, that 
> > > connect to the same server would be able to share TCP/IP channel.
> > 
> > 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.

Indeed, and I would hope we have learnt from those mistakes.


On Fri, 4 Sep 2009, Jonas Sicking wrote:
> >
> > The authors still have to implement it on the server side, though.
> 
> Experience from HTTP shows that there are much fewer HTTP server 
> implementing the HTTP protocol, than there are authors using those 
> servers.

Experience also shows that HTTP is inanely complicated to implement.

The lack of HTTP servers is a bug, not a feature.

WebSockets is designed to be more like CGI than HTTP in terms of 
server-side complexity. Just like there are far more CGI implementations 
than HTTP implementations, I would expect -- and hope! -- that there will 
be far more Web Socket implementations than HTTP implementations.


> >> 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? 
> > 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.
> 
> That's what we do with HTTP today. So I would say yes.
>
> >> 4. If websocket is successful, websocket proxies will likely show up, 
> >> allowing multiplexing across different users that share the same 
> >> proxy.
> >
> > That sounds frightening.
> 
> Again, HTTP benefits from this a lot today.

HTTP is so complicated to implement that few have done so, and those who 
have are typically large teams over many years.

Web Sockets is so simple to implement that you can literally do a fully 
compliant implementation in a few hours (it's about 100 lines of Perl).

This is intentional, and good. But it means that we have to make sure we 
don't add features that can result in serious failures like the above.


On Fri, 4 Sep 2009, Greg Wilkins wrote:
> 
> The server on the server-side could hide the details from the server 
> side developer.

The server-side developer is the one writing the server.


> With HTTP, the server side developer handles requests and has little 
> idea what connection they came over.

This is not HTTP.


> > I don't understand why we'd do that rather than just use two TCP 
> > connections.
> 
> Because TCP connections are not free.  Resources are often allocated 
> server side per connection.  As a server side developer, I would much 
> rather have a little more parsing to do on fewer connections than less 
> parsing on many more connections.

Whether the resources to handle the connections are taken by the OS 
networking stack of the user-space WebSocket stack really doesn't change 
the need for resources.

TCP/IP already supports all we need here. I don't see why we would want to 
reinvent this wheel inside a protocol tunneling through TCP.

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