Re: h2 frame layout

On Sep 2, 2014, at 10:36 AM, Martin Thomson wrote:

> On 29 August 2014 15:49, Roy T. Fielding <fielding@gbiv.com> wrote:
>> I should be shocked that folks are "not concerned" about the use
>> of a 9-octet header and the resulting effect on data alignment
> 
> We're not doing anything to pad frames and maintain alignment, so any
> attempt to align would require that you pad very carefully.  I don't
> see this as a valid argument.

I don't need to pad a 64bit fixed frame preamble, so it isn't difficult
at all after my changes are made.  The difficulty (or waste) of 72bits is
really in how I read data off the network (into buffers) and how I write
data to the network (out of buffers) and the hardware tries to compensate
for non-aligned data.  The other inefficiency occurs when using non-network
representations of the protocol to do application routing.  I don't need
a guarantee of alignment.  What I want is for it to be less statistically
likely on every request/response.

However, I do agree that this is minor compared to the fact that those
extra eight bits aren't even necessary, so sending them in every frame
is pretty stupid for a protocol that is supposed to be efficient.

>>  2) The length is the most random of these fields and used last.
> 
> That depends on the structure of your software.  In one world view,
> the delineation of frames comes before determining their type.

In a world view where the number indicates the total length of the
frame, yes.  But that isn't what is given here.  It is the length of
the frame payload, which comes after the fixed frame preamble.
A smarter design would have allowed some of the standard frames to use
those bits for data instead of payload length (e.g., PING, PRIORITY,
RST_STREAM, and WINDOW_UPDATE), but there is also value in frame
consistency.

The value of starting the preamble with a very consistent number,
like the stream-id, is that it makes visual debugging of framing
errors a whole lot easier.

....Roy

Received on Tuesday, 2 September 2014 18:35:19 UTC