II. Host-Ausfall und Wiederanlauf
Erhebliche Probleme können auftreten, wenn ein Host ausfällt und anschließend versucht, neu zu starten. Zwei Fälle lassen sich leicht unterscheiden. Der erste ist ein „weicher“ Absturz, bei dem das System zuvor erfahren hat, dass die Maschine heruntergefahren wird; es bleibt genügend Zeit, um Wiederherstellungs-Vorkehrungen auszuführen. Der andere Fall kann als „harter“ Absturz bezeichnet werden, oft die Folge eines Systemversagens. Meist wird kaum Warnung gegeben; wichtiger noch: Der Zustand der Maschine nach der Wiederherstellung ist selten vorhersagbar.
Kehrt ein Host nach einem harten Absturz zurück, befindet sich das Netzwerk in einem undefinierten Zustand. Sehr wahrscheinlich sind die Datenstrukturen des NCP zerstört oder bedeutungslos. Das Netzwerk hat den Host für tot erklärt – aber nur gegenüber Prozessen, die eine Datenübertragung versuchten und abgewiesen wurden. Für den abgestürzten Host ist die einzige Möglichkeit die Neuinitialisierung seiner Tabellen. Was sind die Möglichkeiten für die fremden Hosts?
Wir möchten die Ergänzung um zwei Steuerbefehle vorschlagen: RESET (RST) und RESET REPLY (RSR). Jeder würde lediglich aus einem Op-Code ohne Parameter bestehen. Nach Empfang eines RST würde ein Host sofort alle Verbindungen zum sendenden Host beenden, jedoch keine CLSs ausgeben. Der Empfänger des RST würde außerdem festhalten, dass der Urheber des RST am Leben ist, und dem Sender daraufhin ein RSR zurücksenden. Erhält ein Host ein RSR, sollte er festhalten, dass der antwortende Host am Leben ist. (Die Funktion des RST lässt sich teilweise simulieren, wenn ein Host beim Entdecken, dass ein anderer Host ausgefallen ist, sofort alle relevanten Tabelleneinträge schließt.)
So werden nach einem harten Absturz alle Verbindungen und Verbindungsanforderungen beendet. Das RST informiert zudem alle fremden Hosts darüber, dass wir wieder am Leben sind, und von jedem funktionierenden NCP wird ein RSR empfangen. Eine Host-Lebendigkeitstabelle (siehe NWG/RFC #55) lässt sich leicht zusammenstellen, und das Herstellen von Verbindungen kann fortgesetzt werden.
Verwandte Probleme tauchen auch auf, wenn wir versuchen, das Netzwerk, das möglicherweise noch Nachrichten aus der Zeit vor dem Absturz überträgt, mit einem NCP zu synchronisieren, das eine initialisierte Umgebung besitzt. Uns fehlen die Einrichtungen zum Entsperren von Links, zum Verwerfen von Nachrichten usw. – Einrichtungen, die dieser Vorschlag erforderlich machen wird. Eine weitere Abstimmung mit BBN sollte diese Schwierigkeiten beseitigen.
Die mit „weichen“ Abstürzen verbundenen Probleme sind keineswegs so dringend, und sie erfordern ausgefeiltere (das heißt komplexere) Lösungen. Unsere ersten Experimente mit dem Netzwerk zeigen, dass ein gutes Initialisierungs- und Wiederherstellungsprotokoll weitaus notwendiger ist.
Viele der hier dargelegten Ideen wurden durch Gespräche mit Steve Crocker und Jon Postel geboren und/oder reiften zu ihrer endgültigen Form heran. Auch möchten wir die Unterstützung von Jim Balter und Charles Kline von der UCLA dankend anerkennen, die viel Mühe darauf verwandten, bei der Entwicklung des Pseudo-Algol-Programms zu helfen, aus dem ein Großteil unserer neueren Dokumentation hervorgegangen ist.
Hinweis: Dieser RFC wurde von Katsunori Tanaka 2/98 für die Aufnahme in das Online-RFC-Archiv in maschinenlesbare Form gebracht.