Re: 6455 Websockets and the relationship to HTTP

On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion <champion.p@gmail.com> wrote:
>On 12/02/2016 10:02 AM, Patrick McManus wrote:
>>
>> On Fri, Dec 2, 2016 at 12:52 PM, Jacob Champion <champion.p@gmail.com
>> <mailto:champion.p@gmail.com>> wrote:
>>
>>     so that existing clients of WS subprotocol
>>
>> you had me at subprotocol.
>>
>> which one(s)? Pointers to definitions? It would be interesting to see
>> how well that mechanism took off - mostly I've seen it used for
>versioning.
>
>If you mean the registered list:
>
>     https://www.iana.org/assignments/websocket/websocket.xml
>
>It's grown a bit since last I looked. Twenty-five or so?
>
>> but secondarily, sub-protocol negotiation is part of the js api so I
>> probably need a little clarification about what you have in mind as
>the
>> gap you objected to wrt subprotocol. Thanks.
>
>Right, the negotiation itself wasn't so much what my fear was about. 
>I'll need to dig the specs out again, but the two (admittedly minor) 
>gaps that I remember right now are application-data pings and 
>frame-by-frame message streaming. There might be others.

h2 has a PING concept at connection (not stream) level... differences are fixed 8-byte payload instead of up to 126 bytes, and no requirement in h2 that the PONG payload is identical.

I've only ever seen ws PING used as a 'communication still alive' probe, but actually h2 connectivity PING and a PING in the muxed ws2 stream would be semantically different aside from the actual differences.  A PING in the stream can also tell you the ws2 server is still alive, not just the connection to the h2 endpoint.  Ws PING does tell you the ws peer is also up.

So you're probably right ws2 explicit PING is also needed.

>(Since frame boundaries don't have *semantic* meaning in WS, the major 
>thing to keep for WS/2 is the ability to send control frames in the 
>middle of a very large message, which IIUC the WS API does not
>currently 

Nah... if it's sharing an h2 connection, he's just one muxed stream.  And ws specifies any intermediary may refragment ws frames anyway.  Individual ws1 frames have no guarantee of making it to the peer atomically.

Of course ws (see RFC6455 5.4) explicitly "allows" "send[ing] control frames in the middle of a very large message"... a ws message comprises any number of frames of any legal length.  Inbetween the message fragment frames you may send control frames.

So that one is just wrong I think.

>allow. As for pings, the data reflected by the server could allow 
>clients to perform rudimentary latency monitoring or something else 
>clever at the application level, perhaps for clock synchronization...?)

I never saw ws PING data like that; they used their protocol if they had such things.  It's used purely a probe in my experience.

But I think you don't need to make that kind of reach... the ability to confirm the peer who understands ws2 is still up for that stream, like ws PING does, instead of just the h2 endpoint is enough to also require explicit ws2 PINGs as you suggested.

But that's all, over the JS API...

-Andy

>For the record, I'm not currently aware of a *specific* subprotocol
>that 
>would break using only the WS API subset. That would be better answered
>
>by the HyBi experts, I think.

>--Jacob

Received on Friday, 2 December 2016 19:55:24 UTC