Re: Squid, Reload and cache hierarchies

From: Henrik Nordstrom <[email protected]>
Date: Thu, 18 Jul 1996 01:05:07 +0200 (MET DST)

On Wed, 17 Jul 1996, Duane Wessels wrote:

> bortzmeyer@pasteur.fr writes:
> >Explanation: Lynx does a "hard" reload, sending "Pragma: no-cache" but no
> >"If-Modified-Since" while Netscape uses both headers.
>
> >On the other hand, when Netscape reloads, Squid bypasses the hierarchy
> >because of the "If-Modified-Since" :-( (See Release-Notes-1.0.txt.) So,
> >the desire of Netscape to save bandwidth leads to more resource
> >comsuption.

Both should bypass the hierarchy since Pragma: no-cache is set.
Are you inside_firewall with more than one parent? If you are,
then you are probably bitten by a UDP_HIT_OBJ bug. If not then
there is a bug in the hierarchy selection on Pragma: no-cache
(not likely since the Pragma: no-cache is handled with higher
priority that IMS.. IMS is currently ignored on Pragma: no-cache
request).

My response to Duanes writing on change in how IMS is
handled by Squid:

What can be changed the handling of IMS without Pragma: no-cache. These
requests are sent by netscape to validate the contents of a local cache
(against the Squid cache).

Here are a more detailed description about my idea for
IMS handling in future versions of Squid. (geared at
the implications, and not actual implementation)

The basic idea is that IMS (without Pragma: no-cache) is used
to refresh a cached object. There are a number of criterias
needed to make this efficient.
1. The design should not overload top level caches.
2. It is desireable to keep the overall response times
   as short as possible.
3. It is also desireable to present as up to date information
   as possible.
4. Little (long-distance) traffic generated

1, 2 & 4 requires caching.
3 validation with the source site, or no caching.
4 objects are validated agains the nearest parent cache
  and not the source site.

To get the most out of all then there has to be a tradeoff
somewhere since some of the criterias are opposites to each
other, so i propose the following:

1. IMS is used to update cached objects against
   next higher level cache.
2. There is a configurable threshold for how often
   a cached object should be updated, based on some
   of the following criterias
   * Time since last validated
   * Number of hits since last validation
   * Last modified
   * Expiration time
3. A flag if validation should go trought parents
   or directly to the original site (needed if you
   want a different/harder policy than your parent
   caches).

I have the main ideas on how this could be implemented
in Squid, but currently I lack the time to implement it
(I am now working fulltime, leaving very little time
to work on Squid).

If you (or if you know anyone else) think that
you can contribute to the coding, please contact
me as soon as possible. I think that I can provide
all needed details on Squid internals and how IMS
can be implemented, so you don't have to know
all the inner workings of Squid to be able to
help with the coding.

---
Henrik Nordstrom
Received on Wed Jul 17 1996 - 16:06:35 MDT

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