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

On 2014-02-14 09:04, Alex Rousskov wrote:
> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>
>> I'd suggest first to review all possible StoreID use cases involving
>> cache peers before proceeding further.
>>
>> Let's define A as originating proxy and B - as the next hop proxy in
>> the request forwarding chain. UDP is alias for both ICP or HTCP query,
>> while TCP is synonym of the following HTTP request.
>>
>> Here are all valid usage scenarios I could think of:
>> 1. A & B use same StoreID rewiring logic
>> - No StoreID processing for incoming UDP on B is necessary
>> - UDP request uses StoreID
>> - TCP request uses URL
>> 2. A & B use different StoreID rewriting logic
>> - StoreID processing on incoming UDP on B
>> - UDP request uses URL
>> - TCP request uses URL
>> 3. A with StoreID enabled, B - disabled
>> - UDP request uses URL
>> - TCP request uses URL
>> 4. A with StoreIID disabled, B - enabled
>> - StoreID processing on incoming UDP on B
>> - UDP request uses URL
>> - TCP request uses URL
>>
>> In order to support all of the above we need the following two config
>> options:
>> - configuration switch to enable or disable StoreID processing on
>> incoming UDP
>> - cache_peer option to enable/disable querying the respective peer
>> using StoreID instead of URL
>
>
>> If you see any rifts in the above logic, please say.
>
> I question the value of supporting the implied "no StoreID processing"
> optimization above. AFAICT, if Squid always uses URLs for anything
> outside internal storage, everything would work correctly and all use
> cases will be supported well, without any additional options.
>
> If somebody wants to extend ICP/HTCP to include StoreId in the request
> (as an optional additional field), they may do so, but that optional
> optimization does not change the overall design principle: StoreId for
> the internal storage; URL for everything else.

Exactly.

Keeping two distinct cache_peer internal index representations in-sync
with regards to how some helper service is producing the IDs is not as
trivial a job as implied by the proposal.
  Consider the process of upgrading either Squid or the helper on server
A simply *10 seconds* earlier than server B. For that period one of the
services may be pushing garbage cache IDs into the other. In that same
time the latest Squid could process several thousand requests - not
exactly a trivial amount of cache churn.

Also, the connection between those peers is not necessarily a direct
1-hop connection. It may involve any kind of HTTP interception software
(firewalls, deep packet inspectors, etc) overlooked by even the most
well intended administrator.

Amos
Received on Fri Feb 14 2014 - 00:04:30 MST