[ntp:hackers] Asynch resolver

David L. Mills mills at udel.edu
Sun May 7 00:18:11 UTC 2006


Dany,

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.

Dave

Danny Mayer wrote:

> Dave,
>
> 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.
>
>
> Danny
>
> David L. Mills wrote:
>
>> Danny,
>>
>> 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.
>>
>> Dave
>>



More information about the hackers mailing list