Re: Large Frame Proposal

Jeff,


On 9 July 2014 13:25, Jeff Pinner <jpinner@twitter.com> wrote:

>
> 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.
>


So it is your session manager that needs to change from
  max(connection window, stream window).
to
  max(connection window, stream window, settings limit)

you have after all described the setting as session state, so that looks
reasonable in your implementation.


The additional complexity is on checking the validity of the frame
> header against current allowed size and dealing with violations.
>

Well a naive implementation could just set a setting limit of the max frame
size it is willing to accept and then trust that it will never receive a
frame larger than that.      I know that impls should attempt to detect
such protocol violations, but I doubt few will well handle all such
violations.

I guess I accept that for a good impl, it is another parameter to check for
protocol violation and error handling is always a bit of bitch.  But I
guess I just don't see this one as prohibitive complexity given all the
other advantages.

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.