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

On Sat, Oct 29, 2016 at 3:03 AM, Wenbo Zhu <wenboz@google.com> wrote:

> 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.
>

Yes, that's true regarding availability via the WebSocket Web API. In
Chromium, its WebSocket stack transparently fragments messages as it likes,
and because of that, most servers now support it.


>
> On Fri, Oct 28, 2016 at 10:43 AM, Costin Manolache <costin@gmail.com>
> 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 <costin@gmail.com>
>> 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 <tyoshino@google.com>
>>> wrote:
>>>
>>> On Sat, Oct 29, 2016 at 1:25 AM, Costin Manolache <costin@gmail.com>
>>> 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 :)
>>>
>>>
>>>
>