I - Einleitung

In diesem Dokument schlägt die Netzwerk-Arbeitsgruppe am MIT Project MAC Änderungen und Erweiterungen des Protokolls vor, das Carr, Crocker und Cerf in einem Vorabdruck ihres SJCC-Beitrags von 1970 spezifiziert und Crocker in NWG/RFC 36 erweitert haben. Dieses Dokument skizziert unseren Vorschlag in groben Zügen, erhebt aber nicht den Anspruch, eine vollständige Spezifikation zu sein. Es soll Art und Umfang des Protokolls angeben, das unseres Erachtens zunächst implementiert werden sollte.

Wir stimmen dem Grundkonzept einer Simplex-Kommunikation zwischen Sockets mit eindeutigen Bezeichnern zu. Wir schlagen die Implementierung einer leicht abgewandelten Teilmenge der in NWG/RFC36 spezifizierten Netzwerkbefehle vor, ergänzt um den ERR-Befehl, wie er von Harslem und Heafner in NWG/RFC 40 spezifiziert wurde.

Angesichts des grundlegenden Ziels, alle ARPA-Auftragnehmer so früh wie möglich an das Netz anzuschließen und miteinander sprechen zu lassen, halten wir es für wichtig, ein Ausgangsprotokoll zu implementieren, das einigermaßen einfach und dennoch erweiterbar ist und zugleich die wichtigsten anfänglichen Nutzungen des Netzes abdeckt. Es sollte einfach sein, um die breitestmögliche Unterstützung zu gewinnen und an allen Installationen mit minimalem zusätzlichem Softwareaufwand leicht implementierbar zu sein.

Das Protokoll wird sich weiterentwickeln, doch die Grundlagen eines von allen Installationen akzeptierten und implementierten Protokolls werden sich aller Voraussicht nach als sehr änderungsresistent erweisen. Daher ist es sehr wichtig, das Ausgangsprotokoll offen und flexibel zu halten. Ein einfaches Grundprotokoll hat in dieser Hinsicht größere Erfolgsaussichten als ein kompliziertes. Dies schließt nicht aus, dass zwischen mehreren Installationen zusätzliche Protokollschichten bestehen, solange das Grundprotokoll weiterhin unterstützt wird.

Wir sind der Ansicht, dass drei Einrichtungen im Ausgangsprotokoll vorgesehen sein müssen:

1. Mehrwegekommunikation zwischen zwei bestehenden Prozessen, die wissen, wie sie sich miteinander verbinden.

2. Ein Standardverfahren für einen Prozess, sich mit dem Logger (Anmeldeprozess auf einem HOST) eines fernen HOST zu verbinden und die Erzeugung eines Benutzerprozesses zu beantragen. (Das Anmeldungsritual kann standardisiert werden oder auch nicht.)

3. Ein Standardverfahren für einen neu erzeugten Prozess, eine Pseudo-Fernschreiberkommunikation mit dem fernen Prozess aufzunehmen, der seine Erzeugung beantragt hat.

Die wesentlichen Unterschiede zwischen dem von Carr, Crocker und Cerf vorgeschlagenen Protokoll und diesem Vorschlag sind folgende:

1. Die von Crocker in NWG/RFC 36 spezifizierte Strategie der dynamischen Neuverbindung bleibt einer späteren Implementierung vorbehalten. Wir sind der Ansicht, dass ihre Aufnahme die anfängliche Implementierung des Protokolls unnötig verkomplizieren würde. Wir skizzieren eine Strategie zur Erzeugung ferner Prozesse, die keine dynamische Neuverbindung erfordert. Nichts in diesem Vorschlag schließt die Implementierung der dynamischen Neuverbindung zu einem späteren Zeitpunkt aus.

2. Wir schlagen vor, dem Socket-Bezeichner ein "Instanz-Tag" hinzuzufügen, um Sockets zu trennen, die zu verschiedenen Prozessen desselben Benutzers gehören, die auf einem HOST nebeneinander bestehen.

3. Die folgenden NCP-Befehle wurden hinzugefügt:

   1. Der in NWG/RFC 40 spezifizierte ERR-Befehl ist enthalten.

   2. Die Befehle BLK und RSM werden als mögliche Alternativen zum IMP-Befehl "cease on link" sowie zu den in NWG/RFC 36 dargelegten Befehlen SPD und RSM vorgestellt. Da diese Befehle auf Socket-Verbindungen statt auf Link-Nummern wirken, stehen sie der Implementierung einer Multiplexbildung von Socket-Verbindungen über eine einzige Link-Nummer nicht entgegen, falls sich das später als wünschenswert erweisen sollte.

   3. Ein INT-Befehl, der einen Prozess unterbricht, wird spezifiziert. Wir halten es für sehr wichtig, einen Prozess unterbrechen zu können, der möglicherweise in unerwünschte Berechnungen oder Ausgaben verstrickt ist. Die Unterbrechung als Sonderformat innerhalb einer normalen Nachricht zu implementieren, bringt erhebliche Schwierigkeiten mit sich: Die Verbindung kann blockiert sein, wenn die Unterbrechung benötigt wird, und das NCP muss jede eingehende Nachricht nach einem Unterbrechungssignal durchsuchen.

   4. Ein ECO-Echobefehl zum Testen der Kommunikation zwischen NCPs ist enthalten.

4. Sockets werden als Wesen mit mehreren Zuständen konzipiert, und diese stehen in Beziehung zu den Bedingungen, unter denen Netzwerkanforderungen in Warteschlangen eingereiht werden können. Dies unterscheidet sich von der Funktion der unbegrenzten Einreihung, die gewisse Implementierungsschwierigkeiten mit sich bringt.

5. Das Protokoll zur Erzeugung eines fernen Prozesses und zur Kommunikation mit ihm wird auf eine eigene Protokollebene für Benutzersteuerung und -kommunikation (UCC) verlagert und dort vollständiger spezifiziert.