Re: 6455 Websockets and the relationship to HTTP

On 12/01/2016 04:48 PM, Patrick McManus wrote:
> Here's what I think I'm hearing, but there are so many messages that are
> done in the weeds of the solution space I don't want to lose track of
> the problems being solved - I think this list might help in any
> chartering discussion:
>
> * in a practical sense there is no mux and when you have mux you need
> priority and flow control. h2 solves this.
> * operational overhead of maintaining/admin h1 just to boostrap to
> websockets.
> * latency of a new h1 connection just to bootstrap to websockets
> * operational overhead of separate conns for http and ws
>
> is there more? some data on this stuff would be good. Is this really
> mostly about mux?

Multiplexing is interesting but probably a special case that few people 
require, although I can imagine people using it "because they can".

What is more interesting is the flow control (regardless of mux). While 
you can implement a backpressure mechanism on the server by not reading 
from the socket, the flow control allows you to prevent the client or 
the server from sending anything at all, saving resources for other 
connections. This would be a pretty good improvement for RabbitMQ's 
STOMP/MQTT over Websocket, for example.

Ultimately it's just optimizations I think.

WiSH is very interesting because it provides this at minimal costs: same 
framing as Websocket (therefore, same code), existing connection 
handling from H2, HTTP semantics for request routing, methods, content 
negotiation. It could even be used over HTTP/1 should one wish to do so.

I don't think WiSH requires any updates to HTTP to work.

I would be wary of solutions that add new H2 frames, as they require yet 
another implementation. WiSH would work as long as the HTTP semantics 
don't change, and these are shared between HTTP/1 and H2. It's a more 
future proof solution IMO.

-- 
Loïc Hoguin
https://ninenines.eu

Received on Friday, 2 December 2016 09:35:37 UTC