- From: Jeff Pinner <jpinner@twitter.com>
- Date: Tue, 8 Jul 2014 20:25:51 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: David Krauss <potswa@gmail.com>, William Chan (ιζΊζ) <willchan@chromium.org>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
> 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. The allowable data window is separate (at least in my impl) from the frame encoder. The frame encoder has no knowledge of the window size and it relies on the session manager to not write more data then is allowed. The encoder simply takes a streamId and some amount of data (and a flags on whether this data closes the stream) and writes it in frame sized chunks. > 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? The additional complexity is on checking the validity of the frame header against current allowed size and dealing with violations.
Received on Wednesday, 9 July 2014 03:26:18 UTC