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
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:44:02 MST