SETTINGS frame: number of entries?

[James McLaughlin]

In the SETTINGS frame, is the 32 bit "number of entries" field really
necessary? The block for each value is of a fixed length, and the
length of the frame is already known.

James

[Roberto Peon]

Strong utility: It makes for a good sanity check

weak utility: it makes parsing easier after it is decompressed.

moderate utility: I can pre-allocate buffers/pointers/whatever for the various fields and don't have to realloc.

-=R

[Hasan Khalil]

SETTINGS isn't compressed...

[Roberto Peon]

It is true for any/all frames which have variable numbers of fields. :)

In all cases with these kinds of frames, you'll end up with a vector of fields which either contain the keys and values or pointers to the data.

In the case of headers you'll have to have uncompressed the first bit to get at the number of fields, but one must decompress anyway.

On Jun 30, 2012 10:20 AM, "Hasan Khalil" <hkh...@google.com> wrote:

SETTINGS isn't compressed...

[Alek Storm]

I'm not following. What's "true for any/all frames which have variable numbers of fields"?

Knowing the length of the control frame in bytes and the fixed length of the key/value pairs, I can pre-allocate a structure to contain them after consuming only 64 bits of the frame - what does the "number of entries" field get me? With headers, the fields are variable-length, so the "number of entries" field is useful.

What "first bit" do you mean? Do you mean the first four bytes of the name/value header block?

Alek

[Roberto Peon]

When you have a buffer containing n things and you with to index the kth, you generally don't re-parse the frame. You have an in-memory index over the fields.
For servers which care to be efficient, they can pre-allocate the index (in one allocation)while parsing based on the number of fields indicated instead of doing (for a good implementation) O(log(n)) allocations or O(n) allocations.

-=R

[Alek Storm]

Yes, of course. And you can calculate the number of entries as length_field/8. What extra information does the number-of-entries field get you?

Alek

[Hasan Khalil]

Answer: none.

To be more verbose: the number-of-entries field in SETTINGS gives no additional information than what length/8 gets you. I have in the past advocated for its removal, and will do so again here, for SPDY 4.

If SETTINGS were compressed (which, of course, it isn't), then sure I could see its usefulness. Can anyone give any good reasons as to why we should the number-of-entries field in SETTINGS around?

--
    -Hasan

[Roberto Peon]

Fair enough. Fine by me to remove it for frames with a variable number of fixed length fields.

[Mike Belshe]

yeah - its redundant.

[William Chan (陈智昌)]

Did anyone put together a change for this? If not, I'm happy to approve a pull request.