Re: configuring fallback parent

> >The question is: What happens, when the central proxy is not available?
> >We are searching for a clever method, to configure one of the siblings
> >as a fallback parent, that is only used as parent, when the central one
> >fails.
>
> I'm sure you have a good reason, but I'm really curious. Why
> do you need a fallback parent? The sibling caches can just get
> stuff on their own if the parent goes away.

In that case, the siblings have two choices:

 - They get the data directly, without asking any further parents. This
   is unacceptable. This is, what the cache hierarchy is for.

 - They ask our off-campus parent, to which our central proxy would have
   forwarded the request. This is unacceptable for two reasons:

   * It is extra work to reconfigure every sibling, if the outer
     hierarchy changes. This hierarchy should be invisible to the
     sibling caches inside the university. It should only concern the
     central proxy and the fallback machine.

   * The inner configuration should be invisible to the off-campus parent.
     It should have one, or at most two, cleary defined places, from which
     requests are forwarded to the outside.

     The situation in the evolving and growing de-cache hierarchy is,
     that too many top-level parents are asked by too many clients. At
     the moment, most of these top-level parents have rather liberal
     policies, allowing everyone to ask. This should (and must) change
     in the future, so that we can build a real *hierarchy* of caches.
     It would be much easier for our off-campus parent to know exactly
     one or two machines that are allowed to make requests, and block
     all other requests. (Oh by the way, does squid mark a parent dead,
     if it receives too many DENIED replies? If not, this should be
     added.)

So, IMHO, the notion of a fallback is reasonable.

-- 
     Joern Clausen                  email: joern@TechFak.Uni-Bielefeld.DE