Re: hpack static table question?

Guys,

thanks for the explanations. I think I kind of understand now, although I
don't think it really looks "much cleaner" to the proverbial fresh eyes.

Note that I'm not all that worried about the occasional resend of a static
index, or the copy or even the reference set size.   My concern is simply
that a moderately complex design is well justified, well explained and
actually achieves the purpose for which it was intended.

To paraphrase the responses to ensure that I've got it,   the decision to
copy references to static entries to the dynamic table was done so that a
limit on the header table size is also effectively a limit on the reference
set.

In extreme, if the header table size is set to 0, then the reference set
will also have to be empty because there will be no entries for it to
reference.     Known headers will still be able to be sent as index's into
the static table, they will just never make it into the reference set
because they will never fit into the header table.

However, I'm not so sure that this solution really does limit the size of
the reference set, because it can contain duplicates.   Let say that the
header table has exactly one entry in it, then there is nothing to stop a
header block sending repeated references to it so that the reference set
become arbitrarily large with duplicate references?   Personally I'm in
favour of limiting headers to one frame, so that would have an implicit
limit on the size of the reference set as you can only fit in so many index
references into one frame.

cheers

PS.  Anybody care to explain why the static index's are on top of the
dynamic index's?  Is this simply to try to ensure that the dynamic
references are more likely to fit into a 7+bit integer once they are copied?

















On 2 June 2014 18:59, Roberto Peon <grmocg@gmail.com> wrote:

> To expand on what Herve (and I) were saying, by treating these static
> headers like all other headers, the size of the reference set becomes
> constrained by the total memory size, and thus an implementation can cause
> the state to be cleared, or never allocated while allowing indexed
> representations to be used by the encoder.
>  Additionally, assuming one doesn't optimize the copying away (which is
> certainly possible) it becomes possible to use a circular buffer to hold
> all of the data in the compressor. This reduces memory fragmentation and
> can improve CPU cache latency.
>
> IIRC, this was put in 2 or 3 drafts ago. It seemed much cleaner than
> dealing with multiple thresholds (one for ref data, one for memory).
>
> -=R
>
>
> On Mon, Jun 2, 2014 at 9:54 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> This was for safety. This ensures that entries in the reference set get
>> counted, even if the reference set is composed solely of members from the
>> static table.
>>
>> This method was the simplest method for doing so.
>>
>> -=R
>>
>>
>> On Mon, Jun 2, 2014 at 7:45 AM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>>>
>>> The hpack draft 7 says in 3.2.1 : "The referenced static entry is
>>> inserted at the beginning of the header table".
>>>
>>> I can't understand why this copy of a static entry to the dynamic table
>>> is needed?   Doesn't this mean that the static entry will now be known by
>>> two indexes?     Why is this copy needed?  Also If a badly written encoder
>>> kept sending the static index reference, then it would be possible to fill
>>> up the header table with duplicates of the static header?
>>>
>>> I'm also struggling to work out why the indexing is done like:
>>>
>>>           <----------  Index Address Space ---------->
>>>           <-- Header  Table -->  <-- Static  Table -->
>>>           +---+-----------+---+  +---+-----------+---+
>>>           | 1 |    ...    | k |  |k+1|    ...    | n |
>>>           +---+-----------+---+  +---+-----------+---+
>>>           ^                   |
>>>           |                   V
>>>    Insertion Point       Drop Point
>>>
>>>
>>> I would have thought it better to have the tables as:
>>>
>>>           <----------  Index Address Space ---------->
>>>           <-- Static  Table -->  <-- Header  Table -->
>>>           +---+-----------+---+  +---+-----------+---+
>>>           | 1 |    ...    | k |  |k+1|    ...    | n |
>>>           +---+-----------+---+  +---+-----------+---+
>>>                                  ^                   |
>>>                                  |                   V
>>>                             Insertion Point       Drop Point
>>>
>>>
>>> This looks like a very deliberate decision made for good reason... but
>>> the reason alludes me at the moment.
>>>
>>> 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.
>>>
>>
>>
>


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

Received on Monday, 2 June 2014 17:59:34 UTC