[dns-wg] Analysis of NSD

Hi Jay,

On Oct 28, 2004, at 10:40, Jay Daley wrote:

> Johan
>
> Johan wrote on 28/10/2004 09:02:10:
>
>>>    When it comes to zone updates we use a tcp/ip connection to the
>>> master server instead of altering the database directly. We don't 
>>> need
>
>>> to probe for db changes this way.
>>
>> Well, that makes sense, but no one in their right mind is probing for
>> changes since NOTIFY was defined many years ago.
>
> As it happens we use probing not NOTIFY since it gives a greater level 
> of
> control over the number of secondaries being updated at once (and the
> bandwidth) and the order in which they are updated.  This does rely on
> strict calculations of the timings of changes and probes but that is
> fairly easy to do.

Certainly. But that only works if you relax the goal of more or less 
instant propagation of changes (to the slaves). I.e. that way you 
compromise synchronicity (is there such a word?) between slaves for the 
to you more important goal of managing your data streams.

In your case the size of the data is non-trivial, so I understand the 
reasoning.

Johan

PS. I choose the word synchronicity rather than coherence, because as 
long as each slave publish exactly the same data for the same SOA 
serial they are technically coherent (to the version of the data they 
*have*) although they may be temporarily out of sync (with slaves 
having acquiered more recent data).