- From: Takeshi Yoshino <tyoshino@google.com>
- Date: Sat, 29 Oct 2016 03:02:27 +0900
- To: Costin Manolache <costin@gmail.com>
- Cc: Wenbo Zhu <wenboz@google.com>, Loïc Hoguin <essen@ninenines.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CAH9hSJb=o2bXvyrCvRHKWN9TPb-hnTF2nKCRuUqCsN=T6cZEyA@mail.gmail.com>
Thanks. Yeah, they are good candidates. Regarding why we need to have to be able to build so large frame though we have the fragmentation feature, IIRC, the original motivation for this during establishment of RFC 6455 was potential needs to avoid fragmentation e.g. to be able to sendfile() a big file directly into a WebSocket message. I now don't think we need to care this concern so much. On Sat, Oct 29, 2016 at 2: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 :) >> >> >>
Received on Friday, 28 October 2016 18:03:42 UTC