On 9 July 2014 13:01, Jeff Pinner <jpinner@twitter.com> wrote: > I fear the they will happen frequently in practice, requiring dynamic > changes to the frame encoder/decoder. In practice they will likely be > driven by what is seen at the HTTP layer (large uploads/downloads, > file-transfer, etc). > I'm not sure I understand the extra dynamics that you think this proposal requires? Currently a sender must dynamically adjust frame size by max(connection window, stream window). This proposal changes that to max(connection window, stream window, settings limit). That is hardly a significant change. In the receiver, it probably does rule out the simple impl of just allocating a 16KB and expecting a full frame to fit into it. But such naive impls do not actually work in practise as you invariably receive more than one frame in your initial 16KB buffer, so subsequent frames can still wrap over a buffer boundary. The handling you have to do for that is no different to the handling you have to do for large frames. So I still don't see any additional complexity? So can you expand a bit more on your concern because I'm just not seeing it (which is entirely different to not agreeing with it... which I may or may not do once I've understood it). cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Wednesday, 9 July 2014 03:13:38 UTC