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

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.

>> Same logic applies to the URLs for all ICP and HTCP packets:
>> a) queries sent to peers should send client HTTP request URL/URI (*not*
>> StoreID value)
>> b) queries received should convert to StoreID before looking up existence
>> in the local cache.
>>
>> (a) is the bug. (b) is the known missing operation in current StoreID
>> feature.
>
> IMHO, the real bug in the current implementation is using StoreID in
> the TCP session.

AFAICT, the "real bug" is just a side-effect of a true bug (a): The
receiving Squid thinks it is getting a URL but it is being given a
StoreID. However, the patch you posted below seems to be fixing
something else so perhaps I am wrong.

> StoreID over UDP has real benefits in some scenarios,

The only benefit is reduced computation time at the recipient, right? If
somebody cares about that so much they can:

1) Add a StoreID field to ICP/HTCP requests as mentioned above.
2) Use an eCAP adapter instead of a helper to compute StoreIDs.

Cheers,

Alex.

> We did the following quick and dirty hack to fix the TCP problem
> temporary, until a proper resolution is found:
> ===[cut here]===
> --- squid-3.4.3/src/FwdState.cc.orig 2014-02-12 10:01:55.984258244 +0200
> +++ squid-3.4.3/src/FwdState.cc 2014-02-12 09:39:30.620224229 +0200
> @@ -372,6 +373,10 @@ FwdState::startConnectionOrFail()
> {
> debugs(17, 3, HERE << entry->url());
>
> + char *mytemp=strdup(entry->mem_obj->log_url);
> + entry->mem_obj->resetUrls(request->canonical,mytemp);
> + free(mytemp);
> +
> if (serverDestinations.size() > 0) {
> // Ditch error page if it was created before.
> // A new one will be created if there's another problem
> ===[cut here]===
>
Received on Thu Feb 13 2014 - 20:04:06 MST