Re: false hit recovery?

Alex Rousskov wrote:

Yes, I am speaking of the general issue of finding where the
object really is, not only false hits. False hits is only one
side of the coin, connectivity or gateway failures is another
of at least the same priority (esp with the number of MS
servers out there).

> Hmm.. That sounds more like an ICP. I do not think such a
> complex scheme is really needed. A simple round-robin with
> a single global timeout would suffice, IMO. We can "improve"
> the algorithm later.

Sort of serial ICP using HTTP to those peers where we think it
is a HIT, so it's not really ICP. The purpose of this timeout is
to quickly recover from a slow or overloaded sibling.

Yes, this is something that we may improve later on.

Thinking even further. We should probably use a quite short
connect() timeout on the first try to each address, and then
use a substantially longer connect() timeout.

For siblings we may use a short "initial reply" timeout,
except for peers not supporting only-if-cached (and miss_access
is allowed to us).

> OK. If "further" means "guaranteed servers". The algorithm
> outlined does exactly that.

Not quite. As I read it you only tried each address once. The
next step is to retry those origin server or parent addresses
where we failed to get a reply. Siblings should not be retried
as it is quite unlikely we will gain much from that...

> This assumes the object may magically appear on a server.
> Probably useful for errors other than false hits (I was not
> trying to fix those).

Not quite. It assumes that even if a server is unreachable or
malfunctioning at the first attempt, it may be reachable at
the second or third attempt.

> Hmm.. Not important for false hits, but maybe needed for IP- or
> reachability- related errors and such. A "server list iterator"
> should be HTTP-headers- and timeout-aware to handle all those in
> a uniform fashion.

The iteration must be avare of HTTP status codes and
connection failures. It may be avare of some Squid specific
reply header if we wishes to piggy-back extra information other
than a "failure/success" or detect misconfigured cache relations.

The initial address selection should be aware of some request
header to skip peers already probed, but it is not required
to get a working implementation.

> > I think only one header listing false hit servers should be enought

> Sounds good to me. Even if it does not cover some rear cases, it
> makes things simpler.

Much simpler indeed. Especially when interfacing to other brands.

> Right. Plus there is a difference in number of retries for the
> same request. For example, as we agreed, do not try again or try
> other IP addresses of the same server if ERR is a false hit...

Right.

There is a range here of when a address should be retried:

Non-responding origin server: Retry
Malfunctioning origin server: Retry
Non-responding parent: maybe. Must if never_direct.
Malfunctioning parent: Don't retry. Maybe if never_direct.
Sibling: Don't retry.

Note that we do not really need to differentiate between a
false HIT and other errors. What we do need to differentiate
between is if the reply is generated by the origin server or
generated by another proxy. If the reply is generated
by the origin server then it is a final message.

/Henrik
Received on Tue Jul 29 2003 - 13:15:54 MDT