W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: WebSocket2

From: Van Catha <vans554@gmail.com>
Date: Thu, 13 Oct 2016 11:20:22 -0400
Message-ID: <CAG-EYCiyba-3uszv=z3bRH5v+YVUo-3J=w-QC5n_3+OC-y0ybg@mail.gmail.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: Takeshi Yoshino <tyoshino@google.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
> 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 +
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
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
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
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
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
on the server side (not in the case of RFC7692 deflate). If there would be
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.


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.
Received on Thursday, 13 October 2016 15:20:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 October 2016 15:20:55 UTC