Entwurfskonzepte
Die am Netzwerk beteiligten Rechner ähneln sich in zwei wichtigen Punkten: Jeder unterstützt vom Netzwerk unabhängige Forschung, und jeder unterliegt der Disziplin eines Time-Sharing-Systems. Diese Tatsachen trugen zur folgenden Entwurfsphilosophie bei.
Erstens ist es, weil die Rechner im Netzwerk unabhängige Zwecke haben, notwendig, die dezentrale administrative Kontrolle über die verschiedenen Rechner zu bewahren. Da alle Time-Sharing-Supervisoren über ausgefeilte und bestimmte Mechanismen zur Abrechnung und Ressourcenzuteilung verfügen, haben wir die Dinge so eingerichtet, dass diese Mechanismen die durch das Netzwerk verursachte Last auf dieselbe Weise steuern wie die lokal erzeugte Last.
Zweitens schien es, weil alle Rechner unter Time-Sharing-Disziplinen betrieben werden, wünschenswert, grundlegende interaktive Mechanismen zu erleichtern.
Drittens war es, weil dieses Netzwerk von erfahrenen Programmierern genutzt wird, unerlässlich, größtmögliche Freiheit bei der Nutzung des Netzwerks zu gewähren. Beschränkungen hinsichtlich Zeichensätzen, Programmiersprachen usw. wären nicht toleriert worden, und wir haben solche Beschränkungen vermieden.
Viertens hielten wir es, wiederum weil das Netzwerk von erfahrenen Programmierern genutzt wird, für notwendig, den Entwurf offen zu lassen. Wir erwarten, dass mit zunehmender Erfahrung von Zeit zu Zeit Konventionen entstehen werden, fühlten uns aber verpflichtet, sie nicht willkürlich aufzuerlegen.
Fünftens sollte die Softwareschnittstelle zum Netzwerk nur minimale Eingriffe in das Host-Betriebssystem erfordern, um die Teilnahme am Netzwerk komfortabel oder in manchen Fällen überhaupt machbar zu machen.
Schließlich akzeptieren wir die oben genannte Annahme, dass die Netzwerknutzung aus länger andauernden Gesprächen statt aus einmaligen Anforderungen besteht.
Diese Überlegungen führten zu den Begriffen Verbindungen, ein Netzsteuerprogramm, ein Steuer-Link, Steuerbefehle, Sockets und virtuelle Netze.
Eine Verbindung ist eine Erweiterung eines Links. Eine Verbindung verbindet zwei Prozesse, sodass die Ausgabe des einen Prozesses die Eingabe des anderen ist. Verbindungen sind simplex, daher sind zwei Verbindungen erforderlich, wenn zwei Prozesse in beide Richtungen kommunizieren sollen.
Prozesse innerhalb eines Hosts kommunizieren über ein Netzsteuerprogramm (NCP) mit dem Netzwerk. In den meisten Hosts ist das NCP Teil des Betriebssystemkerns, sodass Prozesse Systemaufrufe verwenden, um mit ihm zu kommunizieren. Die Hauptfunktion des NCP besteht darin, Verbindungen aufzubauen, Verbindungen abzubrechen, Verbindungen umzuschalten und den Fluss zu steuern.
Um seine Aufgaben zu erfüllen, muss ein NCP in einem Host mit einem NCP in einem anderen Host kommunizieren. Zu diesem Zweck wurde ein bestimmter Link zwischen jedem Host-Paar als Steuer-Link ausgewiesen. Über den Steuer-Link empfangene Nachrichten werden vom NCP stets als eine Folge von einem oder mehreren Steuerbefehlen interpretiert. Beispielsweise wird eine der Arten von Steuerbefehlen verwendet, um einen Link zuzuweisen und eine Verbindung zu initiieren, während eine andere Art die Benachrichtigung überträgt, dass eine Verbindung beendet wurde. Eine teilweise Skizze der Syntax und Semantik der Steuerbefehle wird im nächsten Abschnitt gegeben.
Ein wichtiges Problem ist, wie man auf Prozesse in einem fremden Host verweist. Jeder Host hat ein internes Benennungsschema, doch diese verschiedenen Schemata sind oft inkompatibel. Da es nicht praktikabel ist, ein gemeinsames internes Benennungsschema für Prozesse aufzuerlegen, wurde ein Zwischen-Namensraum geschaffen, wobei jedem Host ein separater Teil des Namensraums zugewiesen wurde. Es bleibt jedem Host überlassen, interne Prozesskennungen auf seinen Namensraum abzubilden.
Die Elemente des Namensraums werden Sockets genannt. Ein Socket bildet ein Ende einer Verbindung, und eine Verbindung wird vollständig durch ein Paar von Sockets spezifiziert. Ein Socket wird durch die Verkettung von drei Zahlen spezifiziert:
- (a) eine Benutzernummer (24 Bits)
- (b) eine HOST-Nummer (8 Bits)
- (c) AEN (8 Bits)
Ein typischer Socket ist in Abbildung 3 dargestellt.
Jedem Host werden alle Sockets im Namensraum zugewiesen, deren Feld (b) gleich der eigenen Identifikation des Hosts ist.
Ein Socket ist entweder ein Empfangs-Socket oder ein Sende-Socket und wird durch das niederwertige Bit des AEN als solcher markiert (0 = Empfang, 1 = Senden). Die übrigen sieben Bits des AEN stellen einfach eine beträchtliche Anzahl von Sockets für jede verwendete Nummer an jedem Host bereit. (AEN steht für "eine weitere Acht-Bit-Zahl")
Jedem Benutzer wird eine 24-Bit-Benutzernummer zugewiesen, die ihn im gesamten Netzwerk eindeutig identifiziert. Im Allgemeinen ist dies die 8-Bit-HOST-Nummer seines Heimat-Hosts, gefolgt von 16 Bits, die ihn an diesem Host eindeutig identifizieren. Es kann auch Vorsorge dafür getroffen werden, dass ein Benutzer eine Benutzernummer hat, die nicht an einen bestimmten Host gebunden ist — eine Regelung, die für mobile Benutzer wünschenswert ist, die möglicherweise keinen Heimat-Host oder mehr als einen Heimat-Host haben. Diese 24-Bit-Benutzernummer wird dann auf folgende Weise verwendet. Wenn sich ein Benutzer bei einem Host anmeldet, wird seine Benutzernummer nachgeschlagen. Danach wird jeder Prozess, den der Benutzer erzeugt, mit seiner Benutzernummer gekennzeichnet. Wenn sich der Benutzer über das Netzwerk bei einem fremden Host anmeldet, wird dieselbe Benutzernummer verwendet, um die von ihm in diesem Host erzeugten Prozesse zu kennzeichnen. Der fremde Host erhält die Benutzernummer entweder durch Nachschlagen in einer Tabelle zum Zeitpunkt der Anmeldung, wie es der Heimat-Host tut, oder indem er die Identifikation des Anrufers bemerkt. Die Wirkung der Weitergabe der Benutzernummer besteht darin, dass jeder Benutzer sein eigenes virtuelles Netz erzeugt, das aus den von ihm erzeugten Prozessen besteht. Dieses virtuelle Netz kann eine beliebige Anzahl von Hosts umspannen. Somit wird es für einen Benutzer einfach sein, seine Prozesse auf beliebige Weise zu verbinden, während es ihm weiterhin möglich ist, seine Prozesse mit denen in anderen virtuellen Netzen zu verbinden.
Die Beziehung zwischen Sockets und Prozessen lässt sich nun beschreiben (siehe Abbildung 4). Für jede Benutzernummer an jedem Host gibt es 128 Sende-Sockets und 128 Empfangs-Sockets. Ein Prozess kann beim lokalen NCP die Verwendung eines beliebigen Sockets mit derselben Benutzernummer beantragen; dem Antrag wird stattgegeben, wenn der Socket nicht anderweitig in Gebrauch ist. Die entscheidende Beobachtung hierbei ist, dass ein von einem Prozess beantragter Socket nicht bereits in Gebrauch sein kann, es sei denn durch einen anderen Prozess innerhalb desselben virtuellen Netzes, und ein solcher Prozess wird vom selben Benutzer kontrolliert.
Ein ungewöhnlicher Aspekt des HOST-HOST-Protokolls ist, dass ein Prozess sein Ende einer Verbindung von einem Socket auf einen anderen umschalten kann. Der neue Socket kann sich in einem beliebigen virtuellen Netz und an einem beliebigen Host befinden, und der Prozess kann das Umschalten entweder zum Zeitpunkt des Verbindungsaufbaus oder später einleiten. Die allgemeinsten Formen des Umschaltens erfordern eine recht komplexe Implementierung und sind für den Rest dieses Papiers nicht relevant, daher wird nur eine eingeschränkte Form erläutert. Diese eingeschränkte Form des Umschaltens sieht lediglich vor, dass ein Prozess beim Aufbau einer Verbindung einen Socket durch einen anderen ersetzen kann. Der neue Socket muss dieselbe Benutzernummer und dieselbe HOST-Nummer haben, und die Verbindung wird weiterhin zum selben Prozess aufgebaut. Diese Form des Umschaltens ist somit nur eine Möglichkeit, einen Socket neu zu benennen, denn es findet keine Änderung im Routing der Nachrichten statt. Im nächsten Abschnitt dokumentieren wir die Systemaufrufe und Steuerbefehle; im übernächsten Abschnitt betrachten wir, wie die Anmeldung implementiert werden könnte.