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

[Costin Manolache <[e-mail]>]

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