Re: Still not sure how this works...

gtoal@vt.com writes:

> ----+-------------- INTERNET --------------------+----
> | |
> link A (Mexico) link B (USA)
> | |
> | |
> V V
> +-------------+ +------------+
> | | | |
> | | | |
> | Slave cache | <--- fast internal link ----> | Main cache |
> | A | (T1 radio) | B |
> | | | |
> +-------------+ +------------+
> ^ ^
> | |
> | |
> A clients B clients
>
>
>Here's the situation I have: I want to be able to set up cacheing
>such that B clients always get their pages on link B except when
>link B is down, in which case they'll switch to link A.

This is hard. How does cache B know link B is down?
It would be trivial if you have another cache at the other
end of link B.

>I want slave cache A to always pass requests to Main cache B if
>Cache B is actually fulfilling them, but to use link A directly
>if it is not. Note I'm worried about Cache B not fulfilling
>requests because link B is down, not because Cache B is offline.

This is easier, but hard to attain the ideal behaviour.
Squid tracks a error/success ratio for HTTP requests. When
the ratio exceeds 1, Squid will return ICP_OP_MISS_NOFETCH
instead of ICP_OP_MISS. When link A fails, it will take a little
while for the threshold to reach 1, so some users would be
denied access. To configure this you only need to specify B
as a parent in A's config:

    cache_host B parent 3128 3130

>PS Note A clients have no direct path to cache B and vice-versa.
>Both sets of clients must use their own assigned cache.

What we're trying to do here is have the application work around
network layer (or below) failures. I'm not convinced that is a role
caches should be fulfilling. Also, its hard for the application to
tell the difference between link failure and other non-link failures
such as packet loss, etc.

Duane W.
Received on Tue Apr 08 1997 - 16:31:49 MDT