Re: digest only peering?

From: Bruce Campbell <bc@dont-contact.us>
Date: Wed, 25 Nov 1998 18:10:09 +1000 (EST)

On Tue, 24 Nov 1998, Allen Smith wrote:

> On Nov 23, 11:30pm, Alex Rousskov (possibly) wrote:
> > On Fri, 20 Nov 1998, Allen Smith wrote:
> > Perhaps you want to do something like this:
(line 332 of forward.c squid 2.0p2)
       answer = aclCheckFast(Config.accessList.miss, &ch);
> > +#if USE_CACHE_DIGESTS
> > + if (answer == 0 && store_digest) {
> > + answer = cacheDigestTest(store_digest, e->key);
> > + }
> > +#endif
>
> Oh. Oops... this sort of thing is why I requested for someone in the
> situation of needing this to check this out.

I'll be applying it to my main proxy tomorrow, however I won't see
anything until other ISPs which peer with us turn cache-digests back on.

> > Even that is not bullet-proof, but should work in most [reasonable] cases.
>
> Hmm... if the cache digest changed between the peer's loading of it
> and the reception by one's cache of the request, yes, unless I have
> yet again misunderstood the inner workings of squid. What other cases can
> people think of in which this wouldn't work?

It seems to cover the case of fulfilling a request which would otherwise
be denied if we've got a false hit in the (current) cache-digest.

It also covers the case of if a peer retrieves a cache-digest, we discard
an object, the peer then requests the object.

That still leaves a window of up to an hour between when we discard an
object/generate cache-digest without said object, and a when peer
retrieves the latest cache-digest without the object in it, possibly
longer if the peer is disconnected, during which time the peer's client
will get our 'Bugger off, not letting you have this object'.

Hmmm... its starting to get too much effort to keep the previous (X) cache
digests around to deal with that aspect.

Skimming store_digest.c, around line 190 says "this object won't be added
to the digest as we're going to toss it out before the next rebuild", so
that seems to cover most cases, although I'd be inclined to trust in the
Note there and increase that amount of time, ie:

--- squid-2.0.PATCH2/src/store_digest.c.19980920 Wed Nov 25
17:44:40 1998
+++ squid-2.0.PATCH2/src/store_digest.c Wed Nov 25 17:54:41 1998
@@ -74,6 +74,8 @@
 static const int StoreDigestBitsPerEntry = 5;
 /* how often we want to rebuild the digest, in seconds */
 static const time_t StoreDigestRebuildPeriod = 60 * 60;
+/* How much grace time do we want to give objects about to expire? must be larger than StoreDigestRebuild/Rewrite */
+static const time_t StoreDigestGracePeriod = 180 * 60;
 /* how often we want to rewrite the digest after rebuild, in seconds */
 static const int StoreDigestRewritePeriod = 60 * 60;
 /* how many bytes to swap out at a time */
@@ -194,7 +196,7 @@
            (int) (refresh - squid_curtime));
        /* if expires too soon, ignore */
        /* Note: We should use the time of the next rebuild, not cur_time @?@ */
- if (refresh <= squid_curtime + StoreDigestRebuildPeriod) {
+ if (refresh <= squid_curtime + StoreDigestGracePeriod) {
            debug(71, 6) ("storeDigestAdd: entry expires too early, ignoring\n");
        } else {
            good_entry = 1;

--==--
Bruce.

Sysadmin, TheHub.
Received on Wed Nov 25 1998 - 01:28:02 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:43:19 MST