Re: WebSocket2

On Thu, Oct 6, 2016 at 1:29 AM, Van Catha <vans554@gmail.com> wrote:

<snip>


> > Are you suggesting that the WS2/h2 should be indistinguishable from
> HTTP1.1/h2 from
> > intermediaries and server without knowledge of the websocket2- headers
> or
> > application level knowledge? Or just suggesting that we can reduce
> complexity by
> > ignoring all the v2-v1 bridging at proxies?
> >
> > Do you have any strong opinion about how WS2 should be exposed on the
> web platform?
> > The WebSocket API, some brand new API? Or are you only interested in
> defining a
> > standardized messaging protocol to be layered over HTTP2 and QUIC to
> utilize their
> > power?
>
> Standardized protocol or not is irrelevant.  I was simply considering the
> options
> and what would work.  QUIC uses different negotiation and transport frames
> then HTTP/2
> does (also QUIC does not have HTTP/2 SETTINGS frames). I was proposing
> ideas at
> tackling the problem to make WebSocket2 work across different transport
> layers.
>

Got it.

As I explained privately a bit, we're developing the Fetch API
<https://fetch.spec.whatwg.org/> and the Streams API
<https://streams.spec.whatwg.org/> for the web platform to allow for using
bidirectional byte stream over HTTP (over TCP, HTTP2, QUIC, ...). The
transform stream <https://streams.spec.whatwg.org/#ts-model> allows for
implementing e.g. JSON stream parser/serializer, deflate codec (like RFC7692
<https://tools.ietf.org/html/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.

<snip>

> Reading the following revised header proposal, I looks the minimum is 2
> octets.
> > - 2 LZ4 decompressed payload length field's length bits
> > - 2 compression bits
> > - 2 payload length field's length bits
> > - 2 type bits
> > - 1 octet at minimum for text and binary message
> > and 2 + 4 (decompressed byte size) = 6 for LZ4?
>
> I made a typo in the example:
>
> > Now it can look like:
> > b01010100 0x09 0x05 0xAE 0xB4
>
> Should be b01010100 0x03 0x05 0xAE 0xB4
>
>
> The old proposal used 32 bits for payload length and if LZ4 32 bits for
> decompressed
> size. The new way I proposed specifies how many bits those will be by
> setting bits
> in the 8 bit header. So instead of forcing 32 bits always, we can have
> variable
> 8,16,32.
>
> Value of 0 in the payload length (bxxxx00xx) signifies no payload length.
>
> The minimum size of a frame is 1 byte.  Which would be a text or binary
> frame and
> look like:
>
> b00000000
> OR
> b00000001
>

ok


>
> > To me, 4 octet fixed-length payload length header looks competitive for
> its
> > simplicity, but this variable length doesn't compared to the RFC 6455
> length
> > encoding. I understand it ended up to look weird, but it has good
> representation
> > power and efficiency, and there're existing code resources developed for
> > implementing RFC 6455. What do you think about just using RFC 6455's
> length format?
>
> On all accounts RFC 6455 payload length is great.  It also would free
> up 2 bits in the header.
>
> Since the MASK bit is gone (?), maybe it can gain an extra bit.  Also a
> 64bit
> max payload size I think is too much, will we ever want to send any
> message larger
> then 4.3~ gigabyte? I think a MAX_SIZE should be imposed, and one way to
> do this
> without imposing a MAX_SIZE spec is to use a defined amount of bits for
> the lengths.
>

Yeah, MASK is gone as long as there's no risk of confusing non-WS endpoints.

We can choose to just use the extra bit there though it's separated from
the other RSV bits which are in in the first octet.

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?


>
> Both the LZ4 decompressed size and Payload Length can be replaced with the
> RFC 6455 way
> if the mask bit can be freed.
>
>
Yes. We have enough space for the features.


>
> > > Second last 2 RSV bits are for compression.   0 is no compression, 1
> is lz4, 2 is
> deflate.  3 is reversed.
>
> > Unless there we expect needs for switching between the two or more
> compression
> > algorithms in a single connection, we don't need to give a dedicated bit
> for each
> > algorithm.
>
> > The first 2 RSV bits could be also defined as generic compression
> parameter field.
>
> I thought about this, and it does add a nice amount of flexibility at the
> cost of 2
> bits.  For example if your streaming LZ4 compressed data which is often
> 1000 bytes+ per message but
> occasionally get a less than 20 byte message (that gets framed),
> specifying to not
> compress that frame would see a performance/+size benefit.
>

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

Just turning on/off a selected compression could be realized by flipping
the single bit indicating whether the message is compressed or not.


>
> I think we can all agree we do not want to handle decompression in the
> client
> Javascript.
>

<snip>