Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

[Wenbo Zhu <[e-mail]>]

We are not designing the best framing here .. and Takeshi knows this the
best, being through the entire history of websocket discussion.

I think the current encoding scheme for small messages is fine, 1 byte <
125; 3 bytes < 64K; and then 9 bytes for everything else (by this point,
saving 4 bytes at the header of the message won't matter).

BTW, continuation is not widely used, e.g. there is not JS API for this.

On Fri, Oct 28, 2016 at 10:43 AM, Costin Manolache <[e-mail]> wrote:

> Also 24 bit fixed length ( like in http2 frame ) may be a reasonable
> choice, with a 4-byte fixed header.
>
> Costin
>
> On Fri, Oct 28, 2016 at 10:41 AM Costin Manolache <[e-mail]>
> wrote:
>
>> Current overhead is 2 bytes if frame is up to 125 bytes long - which I
>> think it's not very common,
>> 4 bytes for up to 64k, and 10 bytes for anything larger.
>> IMHO adding one byte - i.e. making it fixed 5-byte, with first as is, and
>> next 4 fixed length would
>> be easiest to parse.
>>
>> There are obviously too many options to encode and each has benefits - my
>> only concern was
>> that the choice of 1, 2, 8 bytes for length may not match common sizes.
>>
>> ( in webpush frames will be <4k ).
>>
>> Costin
>>
>>
>>
>> On Fri, Oct 28, 2016 at 10:21 AM Takeshi Yoshino <[e-mail]>
>> wrote:
>>
>> On Sat, Oct 29, 2016 at 1:25 AM, Costin Manolache <[e-mail]>
>> wrote:
>>
>> I think WiSH could be great as a fallback to the webpush protocol push
>> promises, in devices
>> that don't fully support http/2, and for webpush delivery receipts.
>>
>>
>> Great to hear that.
>>
>>
>>
>> In the context of IoT: since continuation is available, any reason to
>> support 64-bit-length frames ?
>> Even 32 bit ( 4G ) frames may be unpractical.  I don't know how common
>> this int encoding scheme
>> is - but using varint or fixed may be easier to handle.
>>
>>
>> It's basically not to introduce any gap with WebSocket's representation
>> power for compatibility while also keeping it efficient for small frames.
>>
>> Re: varint,
>> Actually, old WebSocket protocol I-Ds used base 128 varint for encoding
>> frame length for binary frames.
>> https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00
>> We can choose this as this is efficient for small messages but considered
>> that WebSocket encoding is already common and honored input which led to
>> the WebSocket encoding. IIRC there was some feedback from hardware
>> developer against to 128 varint, but I cannot find it now.
>>
>> Re: big frames,
>> We're also seeing that very long messages are uncommon from Chromium's
>> UMA stats. We might be able to share that.
>>
>> Re: small over head for small frames,
>> For the use cases where WiSH is layered on top of HTTP2 overhead and TLS
>> record overhead, this difference might be negligible.
>>
>> So, ... I'm open to changing the encoding, but want to hear more :)
>>
>>
>>