Interprozesskommunikation zwischen entfernten Prozessen
Das im vorigen Abschnitt beschriebene System lässt sich leicht verallgemeinern, um Interprozesskommunikation zwischen Prozessen an geografisch verschiedenen Orten zu ermöglichen, etwa innerhalb eines Computernetzes.
Man betrachte zunächst eine einfache Anordnung von Prozessen, die um die Punkte eines Sterns verteilt sind. An jedem Punkt des Sterns befindet sich ein autonomes Timesharing-System. Im Zentrum des Sterns existiert ein ziemlich großes, intelligentes Computersystem, das Netzwerk-Controller genannt wird. In diesem Zentralsystem können keine Prozesse laufen; es ist vielmehr als Erweiterung des Monitors jedes Timesharing-Systems im Netz zu betrachten.
Dem Leser sollte einleuchten, dass wir das Problem der Interprozesskommunikation zwischen entfernten Prozessen gelöst haben, wenn der Netzwerk-Controller die Operationen SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY und UNIQUE ausführen kann und wenn alle Monitore in allen Timesharing-Systemen im Netz diese Operationen nicht selbst ausführen, sondern den Netzwerk-Controller bitten, sie für sie auszuführen. Wir haben dann keine weitere Änderung vorzunehmen.
Der Grund, warum alles weiterhin funktioniert, wenn wir die Existenz des Netzwerk-Controllers voraussetzen, ist der, dass der Netzwerk-Controller nachhalten kann, welche RECEIVEs ausgeführt wurden und welche SENDs ausgeführt wurden, und sie einander zuordnen kann, genau wie es der Monitor im Modell-Timesharing-System tat. Ein netzweites Portnummerierungsschema ist ebenfalls möglich, wobei der Netzwerk-Controller weiß, wo (d. h. an welchem Standort) sich ein bestimmter Port zu einem bestimmten Zeitpunkt befindet.
Betrachten wir nun ein komplexeres Netz, in dem es keinen gemeinsamen Mittelpunkt gibt, was es erforderlich macht, die vom Netzwerk-Controller ausgeführten Funktionen auf die Netzknoten zu verteilen. Im Rest dieses Abschnitts werde ich zeigen, dass es möglich ist, die vom sternförmigen Netzwerk-Controller ausgeführten Funktionen effizient und bequem auf die vielen Netzstandorte zu verteilen und dennoch allgemeine Interprozesskommunikation zwischen entfernten Prozessen zu ermöglichen.
An jeder der vier oben beschriebenen SEND/RECEIVE-Operationen müssen einige Änderungen vorgenommen werden, um sie für ein verteiltes Netz tauglich zu machen. Am RECEIVE wird ein Parameter hinzugefügt, der einen Standort angibt, an den das RECEIVE zu senden ist. An SEND FROM ANY und SEND wird ein Standort hinzugefügt, an den das SEND zu senden ist, obwohl dies normalerweise der lokale Standort ist. Sowohl RECEIVE als auch RECEIVE ANY erhalten zusätzlich die Möglichkeit, den Quellstandort jeder empfangenen Nachricht zu ermitteln. Wenn also ein RECEIVE ausgeführt wird, wird das RECEIVE an den angegebenen Standort gesendet, möglicherweise einen entfernten Standort. Gleichzeitig wird ein SEND an denselben Standort gesendet, normalerweise den lokalen Standort des Prozesses, der das SEND ausführt. An diesem Standort, Rendezvous-Standort genannt, wird das RECEIVE dem passenden SEND zugeordnet und die Nachrichtenübertragung zu dem Standort zugelassen, von dem das RECEIVE kam.
Ein RECEIVE ANY verlässt seinen Ursprungsstandort nie, und darin liegt die Notwendigkeit von SEND FROM ANY. Es muss möglich sein, eine Nachricht an einen RECEIVE ANY-Port zu senden, ohne dass die Nachricht am sendenden Standort auf ein RECEIVE wartend blockiert wird. Natürlich wäre es möglich, das System so aufzubauen, dass das SEND/RECEIVE-Rendezvous am RECEIVE-Standort stattfindet und die Operation SEND FROM ANY entfällt, aber nach meinem Urteil wiegt die Möglichkeit, eine normale SEND-Übertragung am Quellstandort zu blockieren, die zusätzliche Komplexität mehr als auf.
Irgendwo an jedem Standort wird eine Rendezvous-Tabelle geführt. Diese Tabelle enthält einen Eintrag für jedes an diesem Standort empfangene, noch nicht zugeordnete SEND oder RECEIVE sowie einen Eintrag für alle an diesem Standort gegebenen RECEIVE ANYs. Ein zusammengehörendes SEND/RECEIVE-Paar wird aus der Tabelle gelöscht, sobald die Zuordnung stattfindet, oder vielleicht, wenn die Übertragung abgeschlossen ist. Wie in der ähnlichen Tabelle des Modell-Timesharing-Systems laufen SEND- und RECEIVE-Einträge ab, wenn sie zu lange nicht zugeordnet werden, und der Urheber wird benachrichtigt. RECEIVE ANY-Einträge werden aus der Tabelle gelöscht, wenn eine sie erfüllende Nachricht eintrifft.
Die letzte notwendige Änderung, um die Funktionen des Netzwerk-Controllers zu verteilen, besteht darin, jedem Standort einen Anteil der eindeutigen Nummern zu geben, den er über seine UNIQUE-Operation verteilt. Auf dieses Thema gehe ich weiter unten noch ein.
Um dem Leser klar zu machen, wie der verteilte Netzwerk-Controller arbeitet, folgt ein Beispiel. Die Einzelheiten, welcher Prozess Portnummern auswählt usw., sind lediglich beispielhaft und keine als Teil des Systems festgelegte Norm.
Angenommen, es gibt zwei Standorte im Netz: K und L. Prozess A am Standort K möchte mit Prozess B am Standort L kommunizieren. Prozess B hat am Port M ein RECEIVE ANY offen.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
Glücklicherweise kennt Prozess A die Existenz des Ports M am Standort L und sendet Nachrichten mit der Operation SEND FROM ANY von Port N an Port M. Die Nachricht enthält zwei Portnummern und Anweisungen für Prozess B, Nachrichten an Prozess A von Port Q an Port P zu senden. Die Standortnummer von Standort K wird zusammen mit dem SEND-Port N dieser Nachricht an die Nachricht angehängt.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ port N /--->SEND FROM --->\ port M /
\________/ ANY \________/
to port M, site L
containing K, N, P, & Q
Prozess A führt nun am Port P von Port Q aus ein RECEIVE aus. Prozess A gibt als Rendezvous-Standort den Standort L an.
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
to site L
containing P, Q, & K
Eine RECEIVE-Nachricht wird von Standort K an Standort L gesendet und in die Rendezvous-Tabelle am Standort L eingetragen. Zu einem anderen Zeitpunkt führt Prozess B von Port Q an Port P ein SEND aus und gibt Standort L als Rendezvous-Standort an.
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & Q
Ein Rendezvous kommt zustande, der Eintrag in der Rendezvous-Tabelle wird gelöscht, und die Übertragung an Port P am Standort K findet statt. Die Nummer des SEND-Standorts (und denkbarerweise auch die Nummer des SEND-Ports) wird den Nachrichten der Übertragung zur Unterrichtung des empfangenden Prozesses angehängt.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
Prozess B möchte möglicherweise gleichzeitig am Port M von Port N aus ein RECEIVE ausführen.
Man beachte, dass es in diesem System nur eine einzige wichtige Steuernachricht gibt, die zwischen den Standorten wandert, nämlich den Nachrichtentyp, der in [3] Host/Host-Protokollnachricht genannt wird. Diese Steuernachricht ist die RECEIVE-Nachricht. Es gibt zwei weitere mögliche standortübergreifende Steuernachrichten: eine Fehlernachricht an den Ursprungsstandort, wenn ein RECEIVE oder SEND abläuft, und die SEND-Nachricht im seltenen Fall, dass der Rendezvous-Standort nicht der SEND-Standort ist.
Natürlich muss es auch ein Standardformat für Nachrichten zwischen Ports geben. Zum Beispiel das folgende:
+-----------------+ +-----------------+ +-----------------+
| rendezvous site | | destination site| | source site |
+-----------------+ +-----------------+ +-----------------+
| RECEIVE port | | RECEIVE port | | RECEIVE port |
+-----------------+ +-----------------+ +-----------------+
| SEND port | | SEND port | | SEND port |
+-----------------+ +-----------------+ +-----------------+
| | | source port | | |
| | +-----------------+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
Anmerkung: Bei einer SEND FROM ANY-Nachricht ist der Rendezvous-Standort der Zielstandort.
Im Modell-Timesharing-System war es möglich, einen Port von Prozess zu Prozess weiterzugeben. Mit einem verteilten Netzwerk-Controller ist dies weiterhin möglich. [Der von der Nützlichkeit der Portweitergabe nicht überzeugte Leser sei auf den Abschnitt über die Wiederverbindung in [11] verwiesen.]
Man erinnere sich, dass für das Senden einer Nachricht von einem Prozess zu einem anderen ein SEND von Port N an Port M und ein RECEIVE am Port M von Port N aus zusammentreffen müssen, normalerweise am SEND-Standort. Beide Prozesse halten nach, wo sie den Rendezvous-Standort vermuten, und geben diesen Standort als Parameter der entsprechenden Operationen an. Der Prozess, der das RECEIVE ausführt, hält sich für den SEND-Standort, und der Prozess, der das SEND ausführt, hält sich normalerweise ebenfalls für den SEND-Standort. Da, sobald ein SEND und ein RECEIVE zusammentreffen, die Übertragung an die Quelle des RECEIVE gesendet wird und der Eintrag in der Rendezvous-Tabelle gelöscht wird und für jede weitere Übertragung von N nach M erneut eingerichtet werden muss, ist es leicht, einen RECEIVE-Port zu verschieben. Wenn ein Prozess sowohl die Portnummern als auch die Nummer des Rendezvous-Standorts an einen neuen Prozess an einem anderen Standort sendet, der unter Verwendung derselben alten Portnummern und derselben Rendezvous-Standortangabe ein RECEIVE ausführt, erfährt der Sender nie, dass der Empfänger umgezogen ist. Etwas schwieriger ist es, einen SEND-Port zu verschieben. Wenn er es jedoch tut, werden das Portnummernpaar, das für ein SEND verwendet worden ist, und die Nummer des ursprünglichen Rendezvous-Standorts an den neuen Standort weitergegeben. Der Prozess am neuen SEND-Standort gibt beim ersten SEND vom neuen Standort aus den alten Rendezvous-Standort an. Der Prozess, der das RECEIVE ausführt, wird ebenfalls weiterhin glauben, der Rendezvous-Standort sei der alte Standort, sodass SEND und RECEIVE am alten Standort zusammentreffen. Wenn sie zusammentreffen, wird der Eintrag in der Tabelle an diesem Standort gelöscht, die Nummer des Rendezvous-Standorts für die SEND-Nachricht wird auf den Standort geändert, der die SEND-Nachricht ausgelöst hat, und sowohl die SEND- als auch die RECEIVE-Nachricht werden an den neuen SEND-Standort gesendet, ganz als wären sie von Anfang an dorthin bestimmt gewesen. SEND und RECEIVE treffen dann erneut am neuen Rendezvous-Standort zusammen, und die Übertragung kann fortgesetzt werden, als hätte sich der Port nie bewegt. Da alle Übertragungen die Nummer des Quellstandorts enthalten, werden weitere RECEIVEs an den neuen Rendezvous-Standort gesendet. Man kann entdecken, dass diese besondere Behandlung stattfinden muss, weil eine SEND-Nachricht an einem Standort empfangen wird, der die SEND-Nachricht nicht ausgelöst hat. Alles lässt sich deshalb so leicht ändern, weil es keine dauerhaften Verbindungen zu trennen und zu verschieben gibt, wie in dem einst für das ARPA-Netz vorgeschlagenen Wiederverbindungsschema [10][11]; das heißt, Verbindungen bestehen in dem hier beschriebenen System nur flüchtig und können daher zwischen jedem Paar von Prozessen neu gebildet werden, die zu irgendeinem Zeitpunkt die Portnummern des jeweils anderen kennen und eine ungefähre Vorstellung davon haben, wo sie sich befinden.
Natürlich hätte all dies auch dadurch geschehen können, dass die Prozesse einander Nachrichten senden und mögliche Umzüge sowie die neuen Standortnummern ankündigen.