Protokolle für die Erstverbindung
Wir möchten zwei Punkte zu spezifischen Initial Connection Protocols (IPCs) anführen. Erstens das in NEW/RFC #66 beschriebene IPC – seine Allgemeinheit und eine Neufassung dieses ICP. Zweitens einen Vorschlag für eine Variante des ICP, die im Wesentlichen dieselbe Logik wie NWG/RFC #66 verwendet.
I. NWG/RFC #66
Der einzige technische Fehler in diesem IPC besteht darin, dass, wie dargestellt, sowohl der Server als auch der Benutzer alle Nachrichten senden, bevor die Verbindungen aufgebaut sind, was mit Network Document No. 1 unvereinbar ist. Dies lässt sich leicht beheben, wie in der Neufassung unten gezeigt wird.
Was die Allgemeinheit betrifft, so sollte jedes als Standard übernommene ICP auf mehr Situationen anwendbar sein als auf einen Prozess, der einen Logger aufruft. Das heißt, einige Netzwerkdienstprozesse, die sich direkt mit einem Benutzerprozess verbinden, unabhängig von der Tätigkeit des Logger, könnten möglicherweise ein Standard-ICP verwenden. Daher sollte, wie unten gezeigt, das Feld für den Prozessnamen des Server-Sockets ein Parameter sein, wobei der Wert null einen Sonderfall für Logger darstellt.
Neufassung von NWG/RFC #66 (unter Verwendung derselben Formulierung, wo angebracht)
- Um den Kontakt einzuleiten, hängt der benutzende Prozess einen Empfangs-Socket (US) an und fordert eine Verbindung zum Prozess SERV, Socket #1 im bedienenden HOST an. (SERV = 0 für das ICP zum Logger.) Infolgedessen sendet der benutzende NCP:
1 4 3 1 1
+-----+---------------------+---------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+---------------------+---------------+-----+-----+
über Link 1, wobei P der Empfangs-Link ist.
- Der bedienende Prozess (SERV) kann beschließen, den Ruf abzulehnen, und schließt in diesem Fall die Verbindung. Wenn er den Ruf annimmt, vervollständigt der bedienende Prozess die Verbindung (über einen INIT-Systemaufruf, daher ein STR).
1 3 1 4
+-----+----------------+-----+--------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+--------------------+
- Wenn die Verbindung hergestellt ist, weist der Benutzerprozess der Verbindung eine nominelle Menge an Platz zu, was dazu führt, dass der NCP sendet:
1 1 4
+-----+-----+--------------------+
| ALL | P | SPACE |
+-----+-----+--------------------+
wobei SPACE die Menge ist.
-
Der bedienende Prozess wählt dann das Socket-Paar aus, das er diesem Benutzer zuweisen möchte. Er sendet genau eine gerade 32-Bit-Zahl über die Verbindung. Diese gerade 32-Bit-Zahl (SS) ist der Empfangs-Socket im bedienenden HOST. Dieser Socket und der nächsthöher nummerierte Socket sind für den benutzenden Prozess reserviert.
-
Dann schließt er die Verbindung. Der bedienende NCP sendet (Schritt 4):
4
+---------------------+
| SS |
+---------------------+
über Link P, und (Schritt 5):
1 3 1 4
+-----+----------------+-----+--------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+--------------------+
über den Steuer-Link (der vom benutzenden NCP zurückgespiegelt wird).
- Da nun sowohl Server als auch Benutzer das entfernte Socket-Paar für die Duplexverbindung kennen, können <STR, RTS>s ausgetauscht werden.
Server sendet an den Benutzer
1 4 4
+-----+--------------------+--------------------+
| STR | SS + 1 | US |
+-----+--------------------+--------------------+---+
| RTS | SS | SS + 1 | Q |
+-----+--------------------+--------------------+---+
wobei Q der Empfangs-Link des Servers ist.
Benutzer sendet an den Server
1 4 4
+-----+--------------------+--------------------+
| STR | US + 1 | SS |
+-----+--------------------+--------------------+---+
| RTS | US | SS + 1 | R |
+-----+--------------------+--------------------+---+
wobei R der Empfangs-Link des Benutzers ist.
Anschließend können ALLocates gesendet und die Übertragung begonnen werden.
II. Eine Variante von NWG/RFC #66
Diese Variante reduziert die Netzwerknachrichten und beseitigt die Duplizierung der Informationsübertragung.
Die Schritte 3 und 4 oben entfallen. Der Benutzerprozess wird nicht direkt benachrichtigt, welchem der Sockets des Servers er zugewiesen wird. Der Benutzerprozess wird jedoch nach Schritt 5 oben auf den Sockets US und US + 1 auf Rufe von SERV warten. Er kann etwaige Störrufe ablehnen. Indem er die Rufe von SERV annimmt, wird die Verbindung hergestellt.
Die folgende Beispielsequenz veranschaulicht dieses ICP. (Die Notation ist wie oben).
- Benutzer --> Server
1 4 3 1 1
+-----+--------------------+----------------+-----+-----+
| RTS | US | SERV | 1 | P |
+-----+--------------------+----------------+-----+-----+
- Server --> Benutzer
Wenn angenommen:
1 3 1 4
+-----+----------------+-----+---------------------+
| STR | SERV | 1 | US |
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
Wenn abgelehnt:
1 3 1 4
+-----+----------------+-----+---------------------+
| CLS | SERV | 1 | US |
+-----+----------------+-----+---------------------+
-
Wenn angenommen, wartet der Benutzer auf US und US + 1.
-
Server --> Benutzer
1 4 4
+-----+--------------------+---------------------+
| STR | SS + 1 | US |
+-----+--------------------+---------------------+---+
| RTS | SS | US + 1 | Q |
+-----+--------------------+---------------------+---+
- Der Benutzer nimmt die Rufe an, daher:
Benutzer --> Sender
1 4 4
+-----+---------------------+--------------------+
| STR | US + 1 | SS + 1 |
+-----+---------------------+--------------------+---+
| RTS | US + 1 | SS | R |
+-----+---------------------+--------------------+---+
und die Verbindung wird hergestellt.
Dies verringert die Anzahl der Netzwerknachrichten um zwei und übergibt die Informationen über die Sockets des Servers nur einmal über RTS und STR.