[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)

[Ian Hickson]

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.


> 2. There are much fewer UA implementors than website authors, so the 
> level of code reuse would be much higher.

The website authors still have to do it even if the UA is the one that 
codes it up on the client side.


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

(Multiple tabs can be done with a shared worker.)


> 4. If websocket is successful, websocket proxies will likely show up, 
> allowing multiplexing across different users that share the same proxy.

That sounds frightening.


> Looking at how much HTTP benefits from "multiplexing" in the form of 
> connection: keep-alive, and how much more it would have benefitted from 
> good multiplexing in the form of pipelineing, I'd be very surprised if 
> websocket wouldn't benefit from it as well.

I agree entirely that we shouldn't keep creating and tearing down 
connections, but Web Sockets are long-lived, so multiplexing doesn't 
really save much on that front. HTTP has a very different interaction 
model than Web Sockets. HTTP wouldn't benefit anywhere near as much from 
true multiplexing as it does from just simple pipelining.


> > I agree that it could be useful for bigger packets; maybe when we 
> > support binary frames we should say that the frames are compressed?
> 
> Well, I'm not sure all binary frames needs to be compressed. For example 
> transmitting a jpeg over websocket should be done in a binary frame, but 
> would unlikely benefit from being compressed. One possible solution is 
> to keep the 0x80 frame type as a raw binary frame, 0x81 is a compressed 
> frame, with the following contents:
> 
> frame-type
> name-of-encoding
> 00
> encoded-contents
> 
> frame-type is a single byte indicating which frame-type is encoded.
> name-of-encoding is a US-ASCII encoded string indicating the name of
> the encoding, this could be 'gzip' for gzipped compression, etc.
> 00 is the single byte with value 0
> encoded-contents is the actual contents, ending at the end of the frame.

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.

Something to look at in a future version, though.

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