Re: 6455 Websockets and the relationship to HTTP

> This is not correct. WebSocket, as a protocol, is distinct from the JS
API. WebSocket, as a protocol, has client->server pings. And there
> are WebSocket client implementations that expose them. Autobahn|Python,
for example.

Yea this is true, but when running over H2/QUIC it kind of loses its
luster.  WebSocket works well when you need to connect to a backend HTTP
server say for a mobile app or non-browser app.  Then you can use some
quality client libraries.

> I think the protocol is more likely to succeed if existing WebSocket
implementations can transparently switch between WS/1 and
> WS/2 transports as needed.

The WiSH RFC was proposed that covered exactly this, there has been a lot
of discussion archived in the mailing related to it.  A lot of the
questions being brought up now have already been answered.  Specifically
related how to keep interop between WS1 while layering on top of H2.

> Andy mentioned that an HTTP/2 transport for WebSocket might mean that we
could get rid of client-to-server masking. I don't have any data
> to support my spitballing, but that *could* be a pretty decent
optimization for implementations, since they no longer have to mask or
> de-mask the data in place. For example, it might open up the possibility
of scatter/gather I/O for frame handling?

See answer above and check out WiSH. This has already been discussed to
great detail.

These discussions would be more productive if we can all get on the same
page with what was already covered in great detail.

https://tools.ietf.org/html/draft-yoshino-wish-00

Masking is not needed anymore, if anyone as knowledgeable in the matter as
Yoshino can suggest why it is, this mailing list is all ears.

WiSH drops ping/pong which is debatable, sure.


> perhaps your goal is that WS/2 should be

WS/2 or simply 2 way binary streaming to drop the WS association.  A basic
method to transmit binary data between two opted in endpoints.



On Mon, Dec 5, 2016 at 1:34 PM, Jacob Champion <champion.p@gmail.com> wrote:

> On 12/01/2016 07:48 AM, 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?
>>
>
> I've contributed to a major derailing of the thread elsewhere. My
> apologies... To try to bring this back to your original point:
>
> Andy mentioned that an HTTP/2 transport for WebSocket might mean that we
> could get rid of client-to-server masking. I don't have any data to support
> my spitballing, but that *could* be a pretty decent optimization for
> implementations, since they no longer have to mask or de-mask the data in
> place. For example, it might open up the possibility of scatter/gather I/O
> for frame handling?
>
> --Jacob
>
>