4. Eine mögliche Anwendung

Gegenwärtig existiert nur ein Computernetz mit Ressourcenteilung, das ARPA-Computernetz. In diesem Abschnitt erörtere ich die Anwendung des in dieser Arbeit beschriebenen Systems auf das ARPA-Netz [2][5][9].

Das ARPA-Netz umfasst gegenwärtig zehn über die Vereinigten Staaten verteilte Standorte. Jeder Standort besteht aus ein bis drei (möglicherweise vier) unabhängigen Computersystemen, Hosts genannt, und einem Kommunikationscomputersystem, IMP genannt. Alle Hosts eines Standorts sind direkt mit dem IMP verbunden. Die IMPs selbst sind untereinander durch 50-Kilobit-Telefonleitungen verbunden (Leitungen mit viel höherer Rate sind eine Möglichkeit), obwohl jeder IMP nur mit ein bis fünf anderen IMPs verbunden ist. Die IMPs bilden ein Kommunikationsteilnetz, über das die Hosts kommunizieren. Daten werden über das Kommunikationsteilnetz in Nachrichten beliebiger Größe (gegenwärtig etwa 8000 Bit) gesendet, die Netznachrichten genannt werden. Wird eine Netznachricht vom IMP am Zielstandort empfangen, so sendet dieser IMP eine Bestätigung, RFNM genannt, an den Quellstandort.

Ein System zur Interprozesskommunikation für das ARPA-Netz (nennen wir es IPC for ARPA) wird gegenwärtig von der Network Working Group unter dem Vorsitz von S. Crocker von der UCLA entworfen. Ihr Entwurf ist durch das Kommunikationsteilnetz einigermaßen eingeschränkt [5]<9>. Ich möchte IPC for ARPA Punkt für Punkt mit dem in dieser Arbeit entwickelten System vergleichen; ein solcher Vergleich würde jedoch zunächst erfordern, hier fast von Grund auf den gegenwärtigen Stand von IPC for ARPA zu beschreiben, da in der offenen Literatur sehr wenig aktuelle Information über IPC for ARPA erscheint [2]. Außerdem ist IPC for ARPA recht komplex, und die Arbeitsdokumente, die es beschreiben, umfassen mittlerweile mehrere hundert Seiten, was jede Beschreibung lang und für diese Arbeit unpassend machen würde.<10> Ich werde daher nur einige verstreute Vergleiche der beiden Systeme anstellen, deren erster in diesem Absatz implizit enthalten ist.

Das für das ARPA-Netz entwickelte System zur Interprozesskommunikation besteht aus mehreren fast getrennten Teilen: dem Host/IMP-Protokoll, dem IMP/IMP-Protokoll und dem Host/Host-Protokoll. Die IMPs tragen allein die Verantwortung dafür, Bits von einem Standort korrekt zu einem anderen zu übertragen. Die Hosts tragen allein die Verantwortung für das Herstellen von Interprozessverbindungen. Sowohl Host als auch IMP sind an Flusssteuerung und Nachrichtenreihenfolge interessiert und tragen dafür ein wenig Verantwortung. Die Anwendung des in dieser Arbeit beschriebenen Systems zur Interprozesskommunikation veranlasst mich zu einer anderen Verteilung der Verantwortung. Der IMP bewegt weiterhin Bits korrekt von einem Standort zum anderen, aber der Netzsteuerungsrechner liegt ebenfalls im IMP, und die Flusssteuerung liegt vollständig in den Händen der in den Hosts laufenden Prozesse, wenngleich unter Nutzung der von den IMPs bereitgestellten Mechanismen.

Die IMPs stellen den Hosts die Operationen SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY und UNIQUE in leicht abgewandelter Form bereit und führen außerdem die Zusammenführungstabellen, einschließlich des Verschiebens von SEND-Ports, wenn nötig. Diese Operationen in den IMP zu legen bedeutet, dass das Programm des Host/Host-Protokolls nur einmal geschrieben werden muss statt vielmals, wie es gegenwärtig im ARPA-Netz geschieht. Es ist vielleicht nützlich, die fünf Operationen noch einmal durchzugehen.

SEND. Der Host gibt dem IMP eine SEND-Portnummer, eine RECEIVE-Portnummer, den Zusammenführungsstandort und eine Pufferangabe (z. B. Anfang und Ende oder Beginn und Länge). Das SEND wird an den IMP des Zusammenführungsstandorts gesendet, normalerweise den lokalen IMP. Trifft ein passendes RECEIVE am lokalen IMP ein, so wird der Host über den RECEIVE-Port der gerade eingetroffenen Nachricht benachrichtigt. Diese Portnummer genügt, um den sendenden Prozess zu identifizieren, obwohl ein gegebenes Betriebssystem möglicherweise interne Tabellen führen muss, die diese Portnummer auf eine brauchbare interne Prozesskennung abbilden. Gleichzeitig beginnt der IMP, vom Host bestimmte Stücke des SEND-Puffers anzufordern, und sendet diese Stücke als Netznachrichten an den Zielstandort. Wird zu lange kein RFNM empfangen, was bedeutet, dass eine Netznachricht im Netz verloren gegangen ist, so werden dieselben Daten erneut vom Host angefordert und erneut übertragen.<11> Mit Ausnahme des letzten Stücks eines Puffers fordert der IMP vom Host Stücke an, die gemeinsame Vielfache der Wortgröße des Quell-Hosts, des IMP und des Ziel-Hosts sind. Dadurch werden Probleme der Wortausrichtung während der Übertragung vermieden.

RECEIVE. Der Host gibt dem IMP einen SEND-Port, einen RECEIVE-Port, einen Zusammenführungsstandort und eine Pufferbeschreibung. Die RECEIVE-Nachricht wird an den Zusammenführungsstandort gesendet. Während die eine Übertragung bildenden Netznachrichten für den RECEIVE-Port eintreffen, werden sie dem Host zusammen mit der RECEIVE-Portnummer (und vielleicht der SEND-Portnummer) sowie einem Hinweis an den Host übergeben, wohin diese Daten in seinem Eingabepuffer zu legen sind. Wird die letzte Netznachricht des SEND-Puffers in den Host übergeben, so wird sie entsprechend gekennzeichnet, und der Host kann dies dann erkennen. (Es ist denkbar, dass die RECEIVE-Nachricht auch ein Stück Netzbandbreite zuteilen könnte, während sie ihren Weg durch das Netz zum Zusammenführungsstandort nimmt.)

RECEIVE ANY. Der Host gibt dem IMP einen RECEIVE-Port und einen Pufferdeskriptor. Dies arbeitet wie RECEIVE, nimmt aber an, dass der lokale Standort der Zusammenführungsstandort ist.

SEND FROM ANY. Der Host gibt dem IMP RECEIVE- und SEND-Ports, den Zielstandort und einen Pufferdeskriptor. Der IMP fordert den Puffer an und überträgt ihn so schnell wie möglich. Ein SEND FROM ANY für einen nicht existierenden Port wird am Zielstandort verworfen.

Im ARPA-Netz wird von den IMPs verlangt, dass die Hosts ihre Übertragungen physisch in Netznachrichten aufteilen, und aufeinanderfolgende Nachrichten einer einzelnen Übertragung müssen verzögert werden, bis das RFNM für die vorherige Nachricht empfangen ist. Im hier beschriebenen System hingegen, da RFNMs an die Übertragung eines bestimmten Pufferstücks gebunden sind und da die Hosts den IMPs erlauben, Puffer in den Hosts wieder zusammenzusetzen, indem der IMP dem Host mitteilt, wohin jedes Pufferstück zu legen ist, können die Stücke eines einzelnen Puffers in parallelen Netznachrichten übertragen werden und mehrere RFNMs können gleichzeitig ausstehen. Dadurch können die Hosts Übertragungen natürlicherer Größe und eine höhere Bandbreite für eine einzelne Übertragung bewältigen.

Zur weiteren Effizienzsteigerung könnte der IMP die ungefähre Zeit kennen, die ein RECEIVE zu einem bestimmten anderen Standort braucht, und den Host warnen, einen Prozess kurz vor dem bevorstehenden Eintreffen einer Nachricht für diesen Prozess zu wecken.