Re: WebSocket2

[Van Catha <[e-mail]>]

> As I explained privately a bit, we're developing the Fetch API and the
> Streams API for the web platform to allow for using bidirectional byte
> stream over HTTP (over TCP, HTTP2, QUIC, ...). The transform stream
> allows for implementing e.g. JSON stream parser/serializer, deflate
> codec (like RFC7692), etc. either in JavaScript or as standardized
> web API implemented in C++, etc., and connecting them to flow data
> efficiently (transfer offloading). This is the story behind the
> WiSH proposal for web browsers. I'm going to explain this more in
> the introduction section of the I-D. Not only Chrome but some other
> vendors are also showing support, experimenting and shipping some of
> them. This might work for your needs.

I am very interested in the Streams API and would even like to contribute,
but I see it as a long road ahead with many questions.  First there is no
framing so how do you handle compression? Ideally with something like
Streams API, you want javascript inbrowser to expose the C++ level RFC7692
deflate/inflate, then you can have full control of your framing +
compression.
I like this scenario the most.  Otherwise Streams API will just turn into
another mutated WebSockets, which sacrificed correctness for simplicity to
developers that know little about writing network services.  I hope the
future
will not follow in these footsteps.

Also LZ4 with levels 1 and 9 I think should be highly considered to be
added as
a compression method alongside of RFC7692.

Google Chrome solved a lot of performance problems with NaCl and hopefully
that will be merged into Chromium soon.  I can see NaCl doing a lot
of the heavy lifting related to Streams API like decoding/encoding protobuf
or even a bitserialized protocol. The possibilities with simple 2 ways
streams
will be endless.

A lot of enterprise rely on NaCl for their B2B and B2C apps.

This NaCl bit is to mention how the future is moving towards C/C++ in the
browser,
so Javascript performance for things like encryption/compression should be
downplayed when considering whether to bake things into the API.

> What did you mean by "to use a defined amount of bits for the lengths"?
> Imposing the limit in the form of the value in the field which specifies
> the length of the payload length field?

I mean that if you only have 32 bits for length the maximum value you can
represent is 4.3~ billion.  Cut that down to 24 bits and its 16~ million.
So you can limit the max framesize from 4.3~ gigabyte to 16~ megabyte by
simply
reducing the amount of bits used for the frame length.

> Did you mean turning on / off LZ4 using the 2 RSV bits?

Yea exactly. It adds a little flexibilty and removes the need to keep a
state
on the server side (not in the case of RFC7692 deflate). If there would be
a
use case for that.  The main benefit I see is if you do not want to
compress small messages say under 20 octets in length.

I updated the RFC for WebSocket2 over HTTP/2 if anyone wants to take another
look, it now has a more solid handshake and a few tweaks to the wire format.

https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt

I still want to push for this WebSocket2 because already the internet runs
on WebSocket, and this will be a smooth transition.

I do believe thought that a Steams API with pure 2 way binary streaming (no
compression, no framing) with C/C++ compressor exposed
through Javascript browser API is the distant future.