Anhang: Eine Anwendung
Derzeit existiert nur ein einziges ressourcenteilendes Computernetz, das oben erwähnte ARPA-Netz. In diesem Anhang hoffe ich zu zeigen, dass das in dieser Notiz beschriebene System auf das ARPA-Netz angewendet werden kann. Zur Interprozesskommunikation innerhalb des ARPA-Netzes existiert bereits ein beträchtliches Werk. Dieses Werk zerfällt in mehrere fast getrennte Teile: das Host/IMP-Protokoll, das IMP/IMP-Protokoll und das Host/Host-Protokoll. In der folgenden Erörterung setze ich Vertrautheit mit diesem Werk voraus. [Siehe die Referenzen [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; und ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.]
Im ARPA-Netz tragen die IMPs allein die Verantwortung dafür, Bits von einem Standort zu einem anderen korrekt zu übertragen. Die Hosts tragen allein die Verantwortung für das Herstellen von Interprozessverbindungen. Sowohl Host als auch IMP sind beteiligt und übernehmen ein wenig Verantwortung für Flusskontrolle und Nachrichtensequenzierung. Die Anwendung des von mir beschriebenen Interprozesskommunikationssystems führt mich zu einer anderen Verteilung der Verantwortung. Der IMP fährt weiterhin damit fort, Bits korrekt von einem Standort zu einem anderen zu bewegen, aber der Netzwerk-Controller liegt ebenfalls im IMP, und die Flusskontrolle liegt vollständig in den Händen der in den Hosts laufenden Prozesse, wenngleich diese vielleicht Mechanismen nutzen, die die IMPs bereitstellen.
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 Rendezvous-Tabellen, einschließlich der Verschiebung von SEND-Ports, wenn dies nötig ist.
Am einfachsten ist es vielleicht, die fünf Operationen noch einmal durchzugehen.
SEND. Der Host gibt dem IMP eine SEND-Portnummer, eine RECEIVE-Portnummer, den Rendezvous-Standort und eine Pufferspezifikation=20 (z. B. Anfang und Ende, Anfang und Länge). Das SEND wird an den Rendezvous-Standort gesendet, normalerweise den lokalen Standort. Wenn das passende RECEIVE eintrifft, wird der Host vom RECEIVE-Port der gerade eingetroffenen Empfangsnachricht benachrichtigt. Diese Portnummer genügt, um den sendenden Prozess zu kennzeichnen, wenngleich ein gegebenes Timesharing-System möglicherweise interne Tabellen führen muss, die diese Portnummer auf nützliche interne Prozesskennungen abbilden. Gleichzeitig beginnt der IMP, den Host nach bestimmten Blöcken des Datenpuffers zu fragen. Diese Blöcke werden nach Maßgabe der RFNM-Steuerung des IMP an das Ziel gesendet. Wird zu lange kein RFNM empfangen, was bedeutet, dass eine Nachricht im Netz verloren gegangen ist, so wird der Host erneut nach demselben Datenblock gefragt [was es auch erlaubt, dass Nachrichten vom IMP-Netz vollständig verworfen werden, falls dies jemals nützlich sein sollte], doch hat der Host zu diesem Zeitpunkt die Möglichkeit, die Übertragung abzubrechen. Während eine Übertragung stattfindet, kann der Host den IMP um andere Operationen bitten, darunter weitere SENDs. Ein zweites SEND über ein Portpaar, das sich bereits in Übertragung befindet, wird vermerkt, und das SEND wird aktiv, sobald die erste Übertragung abgeschlossen ist. Ein drittes identisches SEND führt zu einer Fehlermeldung an den Host. Läuft ein SEND ab, wird ebenfalls ein Fehler zurückgegeben.
RECEIVE. Der Host gibt dem IMP einen SEND-Port, einen RECEIVE-Port, einen Rendezvous-Standort und eine Pufferbeschreibung. Die RECEIVE-Nachricht wird an den Rendezvous-Standort gesendet. Wenn Blöcke einer Übertragung 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, wo die Daten in seinem Eingabepuffer abzulegen sind. Wenn das letzte Stück des SEND-Puffers in den Host übergeben worden ist, wird es entsprechend gekennzeichnet, und der Host kann dies dann erkennen. Ein zweites RECEIVE über dasselbe Portpaar ist zulässig. Ein drittes führt zu einer Fehlermeldung an den Host. Der in diesem und im vorigen Absatz beschriebene Mechanismus erlaubt es einem Prozesspaar, stets sowohl eine Übertragung in Gang als auch die nächste in der Schwebe zu haben. Es geht daher keine Effizienz verloren. Andererseits muss jeder Übertragung ein RECEIVE in einen bestimmten Puffer vorausgehen, was eine vollständige Flusskontrolle ergibt. (Es ist denkbar, dass die RECEIVE-Nachricht ein Stück Netzbandbreite belegen könnte, während sie das Netz zum Rendezvous-Standort durchquert.)
RECEIVE ANY. Der Host gibt dem IMP einen RECEIVE-Port und einen Pufferdeskriptor. Dies funktioniert wie RECEIVE, nimmt aber den lokalen Standort als Rendezvous-Standort an.
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.
RFNMs sind an die Übertragung eines bestimmten Pufferblocks gebunden, genau wie Bestätigungen heute an Pakete gebunden sind, und sie erfüllen dieselbe Funktion. Wenn die Hosts es den IMPs erlauben, Puffer in den Hosts neu zusammenzusetzen, indem der IMP dem Host mitteilt, wohin er einen Pufferblock legen soll, wie oben beschrieben, so können Blöcke eines einzelnen Puffers parallel übertragen werden und mehrere RFNMs können gleichzeitig ausstehen. Die Neuzusammensetzung von Paketen erfolgt weiterhin in den IMPs.
Eine letzte Operation muss vom IMP bereitgestellt werden - die UNIQUE-Operation. Es gibt viele Wege, eindeutige Nummern zu verwalten, und drei werden hier vorgestellt. Die erste Möglichkeit besteht darin, dass die Hosts die eindeutigen Nummern zunächst bei den IMPs anfordern und dann die Integrität aller eindeutigen Nummern garantieren, die derzeit lokale Prozesse und Programme besitzen, und zwar mit welchen Mitteln auch immer dem Host zur Verfügung stehen. In diesem Fall würden die IMPs eine Methode bereitstellen, mit der eine eindeutige Nummer von einem Host zu einem anderen gesendet werden kann, und würden für die Identität der Nummer am neuen Standort bürgen.
Die zweite Methode besteht einfach darin, die eindeutigen Nummern den Prozessen zu geben, die sie verwenden, und sich auf das nicht bösartige Verhalten der Prozesse zu verlassen, um die eindeutigen Nummern zu bewahren, oder, falls ein Unfall geschehen sollte, auf die beiden Passwörter (SEND- und RECEIVE-Ports), die zum Einleiten einer Übertragung erforderlich sind. Werden die eindeutigen Nummern nicht sequenziell ausgegeben und sind sie einigermaßen lang (sagen wir 32 Bits), so ist die Gefahr gering.
Bei der letzten Methode ist eine Benutzerkennung in den Portnummern enthalten, und die einzelnen Timesharing-Systeme garantieren die Integrität dieser Kennungsbits. So kann ein Prozess, auch wenn er nicht sicher sein kann, dass der richtige Port an ihn sendet, doch sicher sein, dass irgendein Port des richtigen Benutzers sendet. Dies ist das von W. Crowther vorgeschlagene sogenannte Konzept des virtuellen Netzes (virtual net) [3].
Verschiedenes. Diese Operationen in den IMP zu legen bedeutet, dass das Host/Host-Protokollprogramm nur einmal geschrieben werden muss, statt viele Male, wie es derzeit im ARPA-Netz geschieht. Die IMPs können die Übertragung eines bestimmten Hosts anhalten (indem sie eine Weile nicht nach dem nächsten Block fragen), wenn dies nötig erscheinen sollte, um Stauprobleme im Kommunikationssubnetz zu lindern. Und der IMP könnte die ungefähre Zeit kennen, die ein RECEIVE braucht, um einen bestimmten anderen Standort zu erreichen, und den Host warnen, einen Prozess kurz bevor es unmittelbar bevorsteht, dass eine Nachricht für diesen Prozess eintreffen wird, aufzuwecken.
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 4/99.