5. Implementation Model (Modèle d'implémentation)
La figure 2 montre l'architecture d'une implémentation multithreadée (multi-threaded implementation) typique. Elle comprend deux processus dédiés à chaque serveur, un processus de pair (peer process) pour recevoir les messages du serveur ou de l'horloge de référence, et un processus de sondage (poll process) pour transmettre des messages au serveur ou à l'horloge de référence.
.....................................................................
. Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline.
. . . . Process .
.+--------+. +-----------+. +------------+ . .
.| |->| |. | | . .
.|Server 1| |Peer/Poll 1|->| | . .
.| |<-| |. | | . .
.+--------+. +-----------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+--------+. +-----------+. | | +-----------+. .
.| |->| |. | Selection |->| |. +------+ .
.|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | .
.| |<-| |. | Cluster | | Algorithm |. |Filter| .
.+--------+. +-----------+. | Algorithms |->| |. +------+ .
. . ^ . | | +-----------+. | .
. . | . | | . | .
.+--------+. +-----------+. | | . | .
.| |->| |. | | . | .
.|Server 3| |Peer/Poll 3|->| | . | .
.| |<-| |. | | . | .
.+--------+. +-----------+. +------------+ . | .
....................^.........................................|......
| . V .
| . +-----+ .
+--------------------------------------| VFO | .
. +-----+ .
. Clock .
. Adjust .
. Process .
............
Figure 2 : Modèle d'implémentation
Ces processus opèrent sur une structure de données commune, appelée association, qui contient les statistiques décrites ci-dessus ainsi que diverses autres données décrites dans la Section 9. Un client envoie des paquets à un ou plusieurs serveurs, puis traite les paquets retournés lorsqu'ils sont reçus. Le serveur échange les adresses source et destination ainsi que les ports, écrase certains champs du paquet et le renvoie immédiatement (en mode client/serveur) ou à un moment ultérieur (en modes symétriques). Lorsque chaque message NTP est reçu, le décalage (offset, theta) entre l'horloge du pair et l'horloge système est calculé avec les statistiques associées delta, epsilon et psi.
Le processus système (system process) comprend les algorithmes de sélection (selection), de cluster et de combinaison (combine) qui atténuent parmi les divers serveurs et horloges de référence pour déterminer les candidats les plus précis et les plus fiables pour synchroniser l'horloge système. L'algorithme de sélection utilise les principes de détection de défaillance byzantine (Byzantine fault detection principles) pour écarter les candidats présumés incorrects appelés "falsetickers" de la population incidente, ne laissant que les bons candidats appelés "truechimers". Un truechimer est une horloge qui maintient la précision du chronométrage selon une norme précédemment publiée et fiable, tandis qu'un falseticker est une horloge qui affiche une heure trompeuse ou incohérente. L'algorithme de cluster utilise des principes statistiques pour trouver l'ensemble le plus précis de truechimers. L'algorithme de combinaison calcule le décalage d'horloge final en faisant la moyenne statistique des truechimers survivants.
Le processus de discipline d'horloge (clock discipline process) est un processus système qui contrôle le temps et la fréquence de l'horloge système, ici représentée comme un oscillateur à fréquence variable (variable frequency oscillator, VFO). Les horodatages obtenus du VFO ferment la boucle de rétroaction (feedback loop) qui maintient le temps de l'horloge système. Associé au processus de discipline d'horloge se trouve le processus d'ajustement d'horloge (clock-adjust process), qui s'exécute une fois par seconde pour injecter un décalage temporel calculé et maintenir une fréquence constante. La moyenne RMS des différences de décalage temporel passées représente l'erreur nominale ou la gigue de l'horloge système (system clock jitter). La moyenne RMS des différences de décalage de fréquence passées représente la stabilité de fréquence de l'oscillateur (oscillator frequency stability) ou la dérive de fréquence (frequency wander). Ces termes reçoivent une interprétation précise dans la Section 11.3.
Un client envoie des messages à chaque serveur avec un intervalle de sondage (poll interval) de 2^tau secondes, tel que déterminé par l'exposant de sondage (poll exponent) tau. Dans NTPv4, tau varie de 4 (16 s) à 17 (36 h). La valeur de tau est déterminée par l'algorithme de discipline d'horloge pour correspondre à la constante de temps de boucle (loop-time constant) T_c = 2^tau. En mode client/serveur, le serveur répond immédiatement ; cependant, en modes symétriques, chacun des deux pairs gère tau en fonction du décalage système actuel et de la gigue système, de sorte qu'ils peuvent ne pas être d'accord sur la même valeur. Il est important que le comportement dynamique de l'algorithme de discipline d'horloge soit soigneusement contrôlé afin de maintenir la stabilité dans le sous-réseau NTP dans son ensemble. Cela nécessite que les pairs s'accordent sur un tau commun égal à l'exposant de sondage minimum des deux pairs. Le protocole NTP comprend des dispositions pour négocier correctement cette valeur.
Le modèle d'implémentation comprend des moyens pour définir et ajuster l'horloge système. Le système d'exploitation est supposé fournir deux fonctions : une pour définir l'heure directement, par exemple, la fonction Unix settimeofday(), et une autre pour ajuster l'heure par petits incréments en avançant ou en retardant l'heure d'un montant désigné, par exemple, la fonction Unix adjtime(). Dans cette référence et les suivantes, les parenthèses suivant un nom indiquent une référence à une fonction plutôt qu'à une simple variable. Dans la conception prévue, le processus de discipline d'horloge utilise la fonction adjtime() si l'ajustement est inférieur à un seuil désigné, et la fonction settimeofday() s'il est supérieur au seuil. La manière dont cela est fait et la valeur du seuil sont décrites dans la Section 10.