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

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 :)
>
>