Re: [squid-users] Re: ICP and HTCP and StoreID

On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote:
>> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote:

<snip>

>>> Would using ICP reqnum field as a cache key or adding StoreID to
>>> ICP/HTCP requests work for your use cases? I have not fully checked
>>> whether the former is possible, but I think it is. The latter is
>>> possible, but is more difficult to implement (and will bump into UDP
>>> packet size limits more often?).
>
>> Yep. Both will do. I personally prefer the second option - StoreID URL
>> normalization on incoming ICP/HTCP request, in order to avoid packet
>> size bumps as much as possible.
>
> Just to make sure we are on the same page, here is a list of options I
> recall being discussed:
>
> 1. Using ICP reqnum field as a cache key.

I don't understand how this option is going to work. AFAIK regnum
is just 4 octets long - how is it supposed to accommodate the StoreID?

> 2. Adding StoreID to ICP/HTCP requests as an optional field.
> 3. Computing StoreID upon receiving a regular ICP/HTCP request.
>
> Out of those three, do you prefer #3? Note that #1 is a little hackish,
> but may be a easier to implement (and is a lot cheaper CPU-wise) than
> #3. Neither #1 nor #3 make the ICP packets bigger, unlike #2.

Option 3 is the only universal solution that works in all scenarios.
Sharing the a StoreID string or a derivative of it
(checksum/hash/digest/whatever) will do only for peers using same
StoreID rewriting logic.

Best,
Niki
Received on Thu Mar 13 2014 - 13:25:04 MDT