[ntp:hackers] Asynch resolver
Brian.Utterback at Sun.COM
Sun May 7 14:32:29 UTC 2006
Best three? Haven't we always maintained that we need four to reliably
detect false tickers? Especially when we are dealing with a pool of
unknown quality servers, I would think it doubly important to have four.
I presume that the actual number is configurable, but I think that if
there is going to be a default, we really need it to be four.
David L. Mills wrote:
> Simple. I would like the pool scheme to operate like manycast. If a
> server falls off the wagon or just gets old, the client should honk and
> expect a pool critter to come back. In fact, the pool management
> algorithms now are identical to manycast with the exception that the DNS
> resolution must come at startup. Once the best three truechimers have
> been found, the rest are tossed away. If one of the good guys is lost,
> there is no way to get it back. What I'd like to do is every couple of
> hours or so, honk for a fresh one and remitigate for the best three.
> Danny Mayer wrote:
>> We are of course supportive of these goals. We would also hope that it
>> helps us in our other ongoing work and if the two can coincide so much
>> the better, but we do understand if it doesn't.
>> Can you explain what *you* mean by dynamic server discovery methodology?
>> I could interpret that in a number of different ways.
>> David L. Mills wrote:
>>> For my student this is an academic exercise. The first goal is to
>>> demonstrate dynamic server discovery methodology, second to use widely
>>> accessable tools, third to preserve portability. In that order, emphasis
>>> added. If the ISC library is well documented and has a moderate learning
>>> curve, that will be considered. So will competing methods. In short, as
>>> I have advised Sachim, the first goal above is the most important and
>>> the quickest way to achieve that is the best.
> hackers mailing list
> hackers at support.ntp.org
More information about the hackers