[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Failing over DNS Server Addresses
From:       "David L. Mills" <mills () udel ! edu>
Date:       2007-08-08 12:56:42
Message-ID: 46B9BD8A.3050707 () udel ! edu
[Download RAW message or body]

Danny,

I've redirected this to hackers@ntp.org as I don't know if all the 
latter are on the ISC list.

I'm the blamee for the mutlicast/manycast stuff. Sachin was working the 
pool issues and, I thought, had it working. Maybe he can speak up.

Dave

Danny Mayer wrote:

> Dave,
>
> I'm going to dub this poolcasting to distinguish it from the manycasting
> you implementing using multicasting.
>
> If Sachim has implemented any of this we'd be glad to integrated or if
> he wants and has time to do so we'd give him whatever help he needs.
>
> I will add this to our todo list.
>
> Danny
>
> David L. Mills wrote:
>
>> Danny,
>>
>> Sachim's original intent was to add a pool command that would tinkle a
>> willing DNS server, parse what came back and prune the population for
>> the three survivors. Code to prune the survivors and manage refresh is
>> already done for manycast and would be easy to use with pool as well.
>> I'm not sure he finished the code or what shape it is in now.
>>
>> THe manycast code wasn't easy. The trick is to age the population after
>> acquisition at a rate coresponding to whether a candidate is the system
>> peer, among the survivors or not. Also considered is whether the straum
>> is below the floor or above the ceiling, which is useful to modulate the
>> scheme, like protect the primary servers, etc.
>>
>> Dave
>

_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]