Re: 6455 Websockets and the relationship to HTTP

On Sun, 2016-12-04 at 19:59 -0500, Van Catha wrote:

> I do not see the need for Ping, Pong or Close ws frames. The h2/quic
> transport layer handles this. If you want to measure latency then
> send your own pings/pongs, do not bake it into the protocol.  There
> is no need for this, and if there is, please present a compelling
> reason.

He's making a slightly different point... there are some corner cases
about ws1 RFC6455 protocol that are not grounded in the JS API,
although almost everything else is.

1) ws1 PING / PONG for example aren't exposed in the JS API at all.

But they are in wide use by non-browser clients, who at intervals want
to confirm their connection to the ws server is still live if it's
idle.

The meaning of ws1 PING is different than the h2 link PING, which is
defined to not be able to have a specific stream context but only
connectionwide.  For ws1 it means the websockets server (which may be a
different process or on a different machine than the h2 endpoint) still
acknowledges the ws1 connection as alive and communication in both ways
on the stream is working.  For h2 it means the h2 server is still
connected at the stream bundle level.  They're not actually giving you
the same assurance.

2) Jacob points out there is implicit serialization in ws1, a fragment
is atomic, blocking PING, PONG and CLOSE until it is all sent.  Again
it's not explicit in the JS API.  But again he's suggesting that
behaviour should be maintained in a ws2.

These are at least reasonable-to-argue points.

> The clientside API should not change, but it should definitely be
> extended OR more functionality should be added to browsers, like the
> ability to compress data from inside JS land.

I dunno.  I implemented permessage-deflate nicely, with good control
over its memory and streaming fixed-size buffers in and out, it can
pass Autobahn, but personally I have never had (or even seen) a good
use for it.  I know some people love it... better to discuss with them
rather than me...

-Andy

> 
> 
> On Fri, Dec 2, 2016 at 4:41 PM, Jacob Champion <champion.p@gmail.com>
> wrote:
> > On 12/02/2016 12:58 PM, Andy Green wrote:
> > > On December 3, 2016 4:18:06 AM GMT+08:00, Jacob Champion <champio
> > > n.p@gmail.com> wrote:
> > > > My point is just that this ability to multiplex control frames
> > > > inside
> > > > of
> > > > in-flight messages is not something that is explicitly exposed
> > > > by the
> > > > JS
> > > > API, but it may be something that a (non-browser) client
> > > > requires for
> > > > proper operation. I think WS/2 should still support it,
> > > > regardless of
> > > > whether or not a JS client can make use of it.
> > > > 
> > >  
> > > OK.  Although the only relevant control frames are PING / PONG.
> > > 
> >  
> > CLOSE too, plus any control frames added to the protocol between
> > now and the release of WS/2.
> > 
> > > And if a client wants to send control frames inside a huge
> > > message, that client must have explicitly fragmented the message
> > > already.
> > > 
> > > The general idea is just map ws2 payload frames direct to h2
> > > framing... refragmenting them to fit.  In that way, 'supporting'
> > > ws1 63-bit frame lengths compatibly doesn't require 63-bit frame
> > > lengths in ws2 because ws always allows refragmentation of
> > > frames.
> > > 
> >  
> > Agreed.
> > 
> > > So it only creates more fragmentation / opportunities to insert
> > > control frames, so no problem.
> > > 
> > > > Let me step back: when you say that your goal is to "provide a
> > > > transport
> > > > for JS WS API on h2", my fear is that this could lead to a
> > > > situation
> > > > where semantics that are part of WS/1 are removed from WS/2 for
> > > > no
> > > > reason other than "Javascript clients don't need it, so no one
> > > > else
> > > > does
> > > > either." I would like to avoid that.
> > > > 
> > >  
> > > What I meant by that is ws1 wire protocol can go out the window
> > > completely.  The job is not wrap ws1 verbatim in h2 frames, keep
> > > ws1 negotiation headers, masking, etc.  It can be radically
> > > recast to align with h2 while following the JS API, and fully
> > > exploit new possibilities like roundtrip elimination.
> > > 
> > > I agree it should make some effort to not break non JS / browser
> > > uses.  But it's no coincidence there are only a tiny number of
> > > corner cases about that -- ws1 was itself designed to implement a
> > > transport for the ws JS API.
> > > 
> >  
> > It sounds like we're on the same page, as long as the eventual
> > solution's authors understand those corner cases, and that the
> > functionality provided by WebSocket is (to a minor extent) a
> > superset of what's provided by the JS API. In particular, I agree
> > that we don't necessarily need to be bound by the current wire
> > format, or the same HTTP-buster security features, as WS/1.
> > 
> > --Jacob
> > 
> > 
> 
>

Received on Monday, 5 December 2016 03:03:50 UTC