Re: #540: "jumbo" frames

On Jun 25, 2014, at 6:53 PM, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> On 26/06/2014, Greg Wilkins <gregw@intalio.com> wrote:
>> 
>> Continuations are jumbo frames!  They are just really bad jumbo frames that
>> only apply to headers, can't be efficiently handled and don't have a
>> mechanism for end points to pre declare max acceptable sizes.   General
>> jumbo frames would handle the headers use-case, but also provide a solution
>> for those who need efficient large data.
>> 
> 
> Data is a single unit, with simple properties for concatenation, so
> it's trivial to split into multiple frames at one end and recombine at
> the other.
> 
> The equivalent metadata unit is the header block, but that doesn't
> have the same recombination properties; so while it can be split into
> multiple frames, there are rules about streaming and interleaving.
> 
> Those rules result partly from the record-based nature of the
> underlying headers, but mostly from the shared state. To eliminate the
> shared state issue I see a couple of options:
> 
> 1) allow multiple header blocks to be sent on one stream, and remove
> continuations. Interleaving wouldn't be a problem, but it wouldn't be
> possible to send large individual headers. More kluge required.
> 
> 1.5) Only compress the HEADERS, make CONTINUATIONs stateless. Pros and
> cons as above.

This option could still support large headers in the uncompressed CONTINUATION frames.

I was just thinking perhaps HEADERS w/ CONTINUATION should require a total multi-frame length? 

One of the biggest problems with CONTINUATION is that a server has no idea how huge the headers will be, and is forced to buffer them until a limit is hit. If this information was known up front it could either RST_STREAM, or simply discard all subsequent CONTINUATION frames and reply with a too large status. 


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Thursday, 26 June 2014 02:15:25 UTC