Zum Hauptinhalt springen

III. Schlussfolgerung

Erweiterungen des Protokolls​

Einige Fragen wurden im aktuellen Protokoll nicht angemessen behandelt. Wir denken an die folgenden Themen, die gründlicher betrachtet und womöglich experimentell erprobt werden sollten.

  1. Ausgefeiltere Flusssteuerung.

    Wie oben erwähnt, werden weitere Schemata zur Flusssteuerung noch erwogen. Abgesehen von der Notwendigkeit, sie in irgendeiner Form bereitzustellen, sind wir uns über die Natur des Problems völlig im Unklaren. Es kann sich herausstellen, dass das gegenwärtige Schema völlig ausreicht; es kann sich aber auch zeigen, dass wir ein weitaus komplexeres Schema benötigen.

  2. Fehlererkennung und -behebung

    Mit zunehmender Erfahrung im Netzwerk werden wir besser verstehen, welche Fehler auftreten können und – vielleicht noch wichtiger – wie mit diesen Fehlern umzugehen ist. Wir erwarten, dass sich das Protokoll mit unserem wachsenden Verständnis der Fehlerbehandlung ändern wird.

  3. Verfahren für Hochfahren und Herunterfahren

    Wir haben uns noch nicht ausreichend Gedanken über das Problem des Hosts gemacht, der nur zeitweise am Netzwerk teilnimmt, der den normalen Netzwerkbetrieb einstellt, aber für besondere Zwecke im Netzwerk verbleibt, oder der sich von einem Systemausfall erholt. Diese Fragen sind für einen robusten Netzwerkbetrieb entscheidend und haben für uns möglicherweise höchste Priorität.

  4. Abfrage und Antwort

    Ein Statustest von Host zu Host wäre ein wertvolles Werkzeug, doch ist noch nicht klar, was sinnvollerweise bereitgestellt werden sollte.

Der Weg ins Netzwerk​

Wir empfehlen, dass Hosts behutsam ins Netzwerk einsteigen. Zunächst sollte jeder Host Verbindungen zu sich selbst gründlich erproben. Danach sollte er Experimente mit einem anderen, bereits funktionierenden Host vereinbaren. Schließlich kann er beginnen, die Einrichtungen anderer Hosts zu nutzen. Derzeit ist noch unklar, welcher Host am besten in der Lage sein wird, anderen Hosts als Erster zu helfen, doch die UCLA wird versuchen, diese Aufgabe zu übernehmen.

Private Vernetzung​

Ein gängiges Vorgehen besteht darin, mehrere lokale Rechner über den IMP zu verbinden, von denen einer oder mehrere nicht dem gesamten Netzwerk zur Verfügung stehen. So verbindet Harvard seinen PDP-1 über einen IMP mit seinem PDP-10; Lincoln Laboratories verbindet seinen TSP über einen IMP mit dem 360/67 und dem TX2; und die UCLA verbindet auf ähnliche Weise einen XDS 920 mit ihrem Sigma-7. In jedem dieser Fälle wird der kleine Rechner dem Netzwerk zunächst keine Dienste anbieten.

Obwohl zu keinem dieser zusätzlichen Hosts unerwünschter Verkehr gelangen sollte, ist es wünschenswert, dass sie sich zumindest minimal an das Netzwerkprotokoll halten. Sofern sie nie selbst eine Verbindung initiieren oder unberechtigte Steuerbefehle aussenden, genügt es, wenn ein Host auf CLS-Befehle mit bestätigenden CLS-Befehlen und auf ECO-Befehle mit ERP-Befehlen antwortet.