Re: source_ping

Alex Rousskov wrote:
 
> AFAIK, it is also used to select a parent closest to the origin site in
> cases when you have a choice between two parents. For example, if at least
> two parents report a digest hit.

Well, technically that is netdb, but netdb data is collected using ICMP
ECHO, and exchanged between peers on top of ICP (if enabled with
query_icmp) and HTTP (unless disabled with no-netdb-exchange on the
cache_peer line).

Areas I am unsure about:

* How it accounts for RTT times to parents, and how/when these gets
updated when conditions changes.

* Is parent RTT time pure ICMP ECHO RTT, or is ICP RTT times taken into
the calculation? (the first only carries network delays, the second also
carries software delays).

* How it behaves when you have a mixed setup of netdb and non-netdb
parents. I think that netdb parents are prefered over non-netdb parents.

* The DIRECT vs peer selection seems a bit strange, but it may work.. I
guess this (and the previous) boils down to the current inflexible code
which selects peers..

* It also feels a bit like the implementation of HTTP netdb exchanges
are a bit premature, sort if in the same state as digest exchanges.
Every hour a complete database is exchanged. The ICP based netdb
exchanges are also far from perfect. I think that the idea of exchaning
netdb data using ICP should be investigated further (or any other UDP
based protocol). HTTP feels like a far from optimal netdb transport
mechanism.

/Henrik
Received on Thu Jan 14 1999 - 12:23:14 MST