Ce qui survit à la perte d’un hôte

Un match survit à la chute de son hôte. Cette page traite de la machine qui possède une entité et de celle qui la possédera ensuite, le second sens de « réplication » ; Qui voit quoi, et sur quelle machine distingue les deux sens.

L’état de la salle n’est pas copié d’un hôte à l’autre

Une entité a exactement un propriétaire à la fois, et aucune autre machine ne garde une copie à jour prête à prendre le relais.

Deux copies qui accepteraient le même tir devraient s’accorder sur l’ordre dans lequel les deux tirs ont porté. S’accorder sur un ordre trente fois par seconde entre plusieurs machines, c’est du consensus, et le consensus ajoute de la latence là où un jeu ne peut pas se le permettre. Un propriétaire unique n’a pas ce problème, et chacun des mécanismes décrits plus bas sert à rendre la perte d’un propriétaire unique supportable.

Ce qui est bel et bien répliqué, c’est la présence : quel acteur se trouve sur quel nœud. C’est une information légère, qui change lentement ; le routage peut donc la connaître partout sans payer le prix d’un accord sur ce qui bouge.

L’état déclaré est conservé hors de l’hôte

L’état déclaré n’appartient pas en propre au processus qui le détient. Un snapshot en est pris à intervalle déclaré : quand l’hôte précédent ne répond plus, un remplaçant peut reprendre à partir du dernier snapshot, et le joueur revient par le délai de grâce (grace window) habituel des salles.

Il en découle deux conséquences, et un avertissement :

Le remplaçant dispose de l’état complet, mais tel qu’il était au moment du snapshot. Un basculement (failover) coûte le jeu écoulé entre le dernier snapshot et la perte, et c’est l’intervalle qui fixe ce pire cas.
La continuité du tick ne survit pas à un changement d’autorité. Un transfert effectué par la plateforme préserve l’état de tick du participant ; un remplacement de l’autorité ne le promet pas. C’est dans Rooms que l’on déclare l’un et l’autre, ainsi que ce qui se passe à la fin du délai de grâce.

L’état qui ne vit que dans le moteur n’est pas récupéré

Ce que vous gardiez uniquement dans des acteurs du moteur disparaît avec le processus. Rien de tout cela n’a jamais été déclaré : aucune machine hors de cet hôte ne l’a donc jamais eu.

Un déploiement suit le même chemin, sans la perte

Retirer un hôte (drain) — ne plus y placer de nouvelles salles (room), laisser les sessions en cours se terminer ou être transférées, puis le libérer — revient à emprunter le chemin du basculement, volontairement et avec préavis. Déployer sans tuer les sessions en direct ne demande donc aucun second mécanisme.

L’hôte de la salle l’apprend comme il apprend tout le reste : la plateforme le prévient à l’avance qu’une salle va être fermée ou transférée pour une raison qui lui est propre.

Ce qui se passe une fois le délai écoulé est déclaré, et il n’y a pas de valeur par défaut. Un type de salle dont l’autorité vit hors de la plateforme choisit l’une des trois issues en cas de perte de cette autorité : attendre la fin d’un délai déclaré, fermer la salle ou admettre une autorité de remplacement. La déclaration ne peut pas passer la question sous silence.

Le choix de la machine ne fait pas partie de votre interface

Vous ne nommez jamais un nœud. Celui qui crée une salle ne choisit pas où elle s’exécute, et aucune opération ne prend un hôte en argument : le placement relève de la plateforme, qui peut donc déplacer une salle sans que votre code dépende de l’endroit où elle se trouvait.

Si vous hébergez vous-même des salles — sur un serveur dédié ou un client maître —, il en va de même, à une chose près : on vous demande de vous arrêter, et c’est à vous de terminer ou de transférer vos sessions pendant le délai de grâce. Rooms explique comment un hôte s’enregistre pour ce binding, et Qui prend les décisions explique pourquoi l’hôte ne détient que les droits qui lui ont été accordés.