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

Amos,

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

NB! I didn't analyze the relevant Cache Digest scenarios, as I don't
have any experience using them. Based on my shallow understanding on
the topic, I'd suggest another cache_peer option - enable or disable
StoreID for querying the cache digest of the respective peer. This
feature will have one caveat: works only in case of B using the same
StoreID rewriting logic as A. I don't believe there's a viable option
to support different StoreID logic for cache digest.

If you see any rifts in the above logic, please say.

> 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. It actually prevents using StoreID and cache_peer
simultaneously I could not see a real-world scenario that will need
such behaviour.
StoreID over UDP has real benefits in some scenarios, so let's
consider the current implementation as "incomplete" or "limited"
instead of "bug".

My suggestion is first to fix the TCP problem, then we could focus on
extending the UDP-related features.

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]===

All comments are welcome.

Best,
Niki
Received on Thu Feb 13 2014 - 12:12:34 MST