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 doesn't, but it does know that it is getting timeouts when it requests
pages from that link. And I'll rephrase that a little: "when link B is not
supplying pages, for whatever reason"

> It would be trivial if you have another cache at the other
> end of link B.

True, unfortunately it's not an option unless we go to a cache much further
afield than the end of the link (which is run by one of the big backbone
providers, who isn't going to put in a squid cache just for us...)

I haven't yet tried linking up to the other squid caches on the net
so I don't know how much benefit (hurt?) you get from accessing a distant
cache as opposed to going to all the sites directly. I suspect some
sites are quicker and others slower, but I don't know if it averages
out equal or worse. When you say it would help for me to have another
squid cache on the end of the link, do you mean so that all requests
are fulfilled by that cache, or just the ones where it replies faster
than the actual site itself? If the latter, I guess I could just hook
up to the master squid cache?

> >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.

We can live with that, when the alternative is that I get a pager message
that a monitored web site is not responding and I have to find a computer,
log in, and manually switch the CERN proxy over to using the other method!
Less than ideal...

> >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.

You're entirely right; I realise it is not ideal, but I'm stuck
with it for reasons outside my control. I can see more of this happening
as people arrange informal backup links to multiple companies and are
stuck with non-portable, non-routable addresses; sometimes even dynamically
changing addresses such as from a dynamic PPP connection over ISDN.
It's a thing worth supporting I promise; or at least, a thing not worth
going out of your way to suppress :-)

> 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.

I'm not sure I care that much what the reason for the failure is actually;
if I'm not getting the pages from the one cache I want to switch to the
other regardless.

Thanks for the explanation; I appreciate it.

Graham
Received on Wed Apr 09 1997 - 10:28:56 MDT