Re: 6455 Websockets and the relationship to HTTP

> It's a valid topic for discussion as to whether enough people care or
> not to define a way to get the same functionality in ws2...

Agreed here is my take on it.

WS1 was batteries included.  PING/PONG also was critical as you could have
a zombie socket
(send does not fail, but data not delivered to endpoint). If you send ping
from serverside you can
destroy the zombie clients if no pong comes.  BUT what WS1 did not consider
is you could have a zombie socket from
client->server, WS1 did not expose any API to check ping/pong this way.
There is no onping/onpong
callback, nor is there a ws.send_ping function in browser side js.

So essentially the Ping/Pong baked into WS1 was half useless and you had to
roll your own pings/pongs ontop of
the WS1 transport layer.

Ping / Pong to ensure an endpoint is alive is crucial but it needs to be
sent from the client, WS1 browser
client API never exposed this.

So to repeat making the mistakes of the past we have two options. #1 Take
ping out altogether as its broken, no browser
client implemented the ability to send pings to server. #2 Extend WS
browser API to allow sending ping/pong.

Now enter H2 and QUIC, which has their own transport layer that guarantee
an endpoint will be alive. If not you will get
notified a stream is dead.  If the h2 is running in a distribution, it is
up to the internals of h2 to determine if a distributed node
in the system died, and to notify the client the connection was closed on
those streams.

The case of ping is important to not have to wait a certain timeout for h2
to determine a distributed node died and notify the client.
The case of ping is important to be re-enforced you are connected.

The simplest way I see is to make websocket protocol agnostic, its just a
binary stream, and let userland handle the protocol (pings, pongs etc).
What if one user wants to trammit a ticktime in the ping, etc.  Its simply
not flexible enough to be baked in.

If one is to consider baking in pinging just to determine if the h2 stream
going to your Websocket APP is not flooded due to your apps slow
consumption, they should not burden the protocol with personal problems.

On Sun, Dec 4, 2016 at 10:58 PM, Andy Green <andy@warmcat.com> wrote:

> On Sun, 2016-12-04 at 22:23 -0500, Van Catha wrote:
> > > 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.
> >
> > That is the responsibility of the h2 endpoint (if h2 is
> > proxing/forwarding the request to another server).
> >
> > I do not see why this should be the responsibility of ws.  I see your
>
> Ws1 already does that and it's in wide use.
>
> Telling people to use the mux ping on h2 will be a departure in
> functionality from ws1.  And depending how its put together, the guy
> that binds streams in h2 may not have a way for the child streams to
> request / see / manage delivery of h2-connection-level h2 PING/PONGs
> that are already defined to not have any stream index other than zero.
>
> It's a valid topic for discussion as to whether enough people care or
> not to define a way to get the same functionality in ws2...
>
> > point, but I see it as out of scope.
>
> ...ws1 found it "in scope".
>
> -Andy
>
> > On Sun, Dec 4, 2016 at 10:02 PM, Andy Green <andy@warmcat.com> wrote:
> > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>