Zusammenfassung
- RFC 992 behandelte Ausfall und Wiederkehr als geordnete Gruppenmeldungen, damit die aktiven Prozesse dieselbe Folge von Mitgliedschaftsänderungen sehen.
- GBCAST ordnete die Gruppenansicht, ABCAST brachte gemeinsame Operationen in dieselbe Reihenfolge, CBCAST bewahrte Ursache und Wirkung und ließ unabhängige Arbeit parallel laufen.
Eine Arbeitswarteschlange liegt auf drei Rechnern. Ein Auftrag verlangt, den ersten Eintrag herauszunehmen. Während die Nachricht unterwegs ist, bleibt einer stehen. Rechner A sieht den Auftrag vor der Ausfallmeldung, Rechner B sieht die Ausfallmeldung zuerst. Beide haben Strom und können rechnen. Doch A hat den ersten Auftrag schon entfernt, während B ihn noch auf Platz eins führt. Der nächste Kunde erhält je nach Rechner einen anderen Auftrag. Der Dienst hat den Ausfall überstanden und seine gemeinsame Warteschlange verloren.
Kenneth Birman und Thomas Joseph beschrieben diese Rennsituation im RFC 992 vom November 1986, entstanden aus der ISIS-Forschung an Cornell. RFC 966 und RFC 988 befassten sich bereits mit Hostgruppen und Multicast. Die Cornell-Frage zielte auf den Augenblick, in dem sich die Empfängerliste während der Zustellung ändert. Was bedeutet eine Nachricht an „die Gruppe“, wenn zwei Empfänger verschiedene Fassungen dieser Gruppe vor Augen haben?
Die strengste Antwort hieß GBCAST. Ein zurückgekehrtes Mitglied meldete seine Wiederkehr; bei einem Ausfall verschickte das System die Nachricht für den ausgefallenen Prozess. Der Tote bekam einen Sprecher. Diese Meldung wurde mit gewöhnlichen Multicasts geordnet. Wenn ein Empfänger den Arbeitsauftrag vor der Ausfallmeldung sah, mussten gemeinsame Empfänger dieselbe Reihenfolge sehen. Frühere Nachrichten des ausgefallenen Senders standen vor seiner eigenen Ausfallanzeige. Jedes Mitglied führte eine VIEW, seine Liste der Gruppenmitglieder.
Die Listen sprangen zu unterschiedlichen Zeiten um, durchliefen aber dieselben Änderungen in derselben Reihenfolge. Für eine bestimmte Nachricht benutzten die Empfänger dadurch dieselbe Mitgliederliste.
GBCAST war die teure Sitzung des Ausschusses. Für jede Kleinigkeit wäre sie zu langsam gewesen. ABCAST lieferte Nachrichten mit gleicher Kennzeichnung bei gemeinsamen Empfängern in gleicher Reihenfolge, passend für die Operationen einer replizierten Warteschlange. CBCAST erhielt nur die Reihenfolge kausal verbundener Nachrichten und ließ unabhängige Vorgänge ohne gemeinsames Marschtempo arbeiten. Die drei Verfahren waren eine Preisliste für Abstimmung: starke Ordnung, wo verschiedene Zustände den Dienst spalten würden; weniger Ordnung, wo Gleichzeitigkeit einen Gewinn bringt.
Das Papier setzte stoppende Ausfälle und eine Erkennung dieser Ausfälle voraus. Seine Werte für Arbeitsplatzuhren und Übertragungszeiten waren Beobachtungen aus der damaligen Laborumgebung und erklärten, warum Uhrzeiten allein den Wettlauf kaum entscheiden konnten. Die Autoren berichteten von einem abgeschlossenen früheren ISIS-Prototyp und einer neuen Implementierung im Aufbau. Der bleibende Gedanke ist handfest: Sobald ein Ausfall bestimmt, wer einen Auftrag ausführen darf, gehört auch die Ausfallmeldung zum Protokoll der Aufträge.
Der abgestürzte Rechner verpasste die Besprechung. Wenigstens erhielten die anderen das Protokoll in derselben Reihenfolge.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten





