Résumé

  • Le RFC 992 intégrait les annonces de panne et de retour dans la diffusion ordonnée d’un groupe de processus, pour que les membres actifs partagent la même vue des événements.
  • GBCAST ordonnait les changements de composition, ABCAST alignait les opérations communes et CBCAST préservait les liens de causalité sans immobiliser les messages indépendants.

Prenons trois copies d’une file d’attente. Un client demande de retirer le premier travail au moment précis où l’une des machines s’éteint. Deux survivantes suffisent pour continuer le service. Encore faut-il qu’elles sachent si l’ordre est arrivé avant ou après la nouvelle de la panne. Si chacune raconte une chronologie différente, la redondance vient d’offrir deux versions du même service. La machine défaillante a réussi un dernier exploit : laisser ses collègues se quereller.

C’est ce problème que Kenneth Birman et Thomas Joseph examinent dans le RFC 992, publié à Cornell en novembre 1986 dans le cadre des recherches ISIS. Les RFC 966 et RFC 988 traitaient déjà des groupes d’hôtes et de la multidiffusion. Ici, la question se déplace vers l’instant où la liste des destinataires change pendant qu’un message circule. Une livraison « au mieux » laisse alors une incertitude qui remonte jusque dans les décisions de l’application.

Le premier outil, GBCAST, traite la panne ou le retour comme un message du groupe. Lorsqu’un processus meurt, le système expédie l’annonce à sa place. Le défunt n’a pas demandé la parole, mais il obtient un communiqué. L’essentiel tient à l’ordre : si un membre reçoit un message ordinaire avant l’annonce, les destinataires communs doivent observer la même séquence. Les messages émis auparavant par le membre disparu précèdent sa notification de panne. Chaque participant tient ainsi une VIEW, une liste de membres qui évolue selon la même suite de changements.

Il n’existe pas de coup de sifflet simultané sur toutes les horloges ; il existe une histoire commune.

Cette discipline a un prix. Les auteurs réservent GBCAST aux changements de composition et à quelques décisions globales, comme le rang des membres, les points de reprise et la migration d’un processus. Pour le travail quotidien, ils proposent ABCAST et CBCAST. ABCAST ordonne de la même façon, chez les destinataires communs, les messages portant une même étiquette : c’est utile à une file répliquée. CBCAST impose l’ordre quand un message dépend causalement d’un autre et libère les messages indépendants.

Trois outils, trois factures de coordination ; acheter le plus cher pour chaque envoi aurait transformé la disponibilité en cérémonie interminable.

Le modèle décrit des arrêts nets et une détection des pannes. Les chiffres de l’article sur les horloges de stations de travail et les délais du réseau appartiennent au laboratoire des années 1980 ; ils expliquent pourquoi les auteurs se méfiaient d’un arbitrage par le temps seul. Leur texte présente une architecture de recherche et une mise en œuvre alors en chantier. Sa trouvaille durable reste concrète : quand la disparition d’un membre change le sens d’une instruction, la nouvelle de cette disparition doit suivre les règles de livraison de l’instruction.

La panne n’a pas besoin d’être polie. Les survivants, si. Ils doivent au moins s’accorder sur la page où le personnage a quitté l’histoire.