About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: [dns-wg] Analysis of NSD

  • To: Jay Daley < >
  • From: Johan Ihrén < >
  • Date: Thu, 28 Oct 2004 10:48:46 +0200

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).



<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community