3. Ein System zur Interprozesskommunikation zwischen entfernten Prozessen
Das im vorigen Abschnitt beschriebene IPC lässt sich leicht verallgemeinern, um Interprozesskommunikation zwischen Prozessen an geografisch verschiedenen Orten zu ermöglichen, wie zum Beispiel innerhalb eines Computernetzes.
Man betrachte zunächst eine einfache Anordnung von Prozessen, die um die Punkte eines Sterns herum verteilt sind. An jedem Punkt des Sterns gibt es ein autonomes Betriebssystem<5>. Im Zentrum des Sterns befindet sich ein ziemlich großes, intelligentes Computersystem, das Netzsteuerungsrechner (Network Controller) genannt wird. In diesem zentralen System können keine Prozesse laufen; vielmehr ist es als eine Erweiterung des Monitors jedes der Betriebssysteme im Netz zu betrachten.
Ist der Netzsteuerungsrechner in der Lage, die Operationen SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY und UNIQUE auszuführen, und führen alle Monitore aller Time-Sharing-Systeme im Netz diese Operationen nicht selbst aus, sondern bitten den Netzsteuerungsrechner, sie für sie auszuführen, so ist das Problem der Interprozesskommunikation zwischen entfernten Prozessen gelöst. Weitere Änderungen sind nicht nötig, da der Netzsteuerungsrechner nachverfolgen kann, welche RECEIVEs und welche SENDs ausgeführt wurden, und sie genau so zur Deckung bringen kann, wie es der Monitor im Modell-Time-Sharing-System tat. Ein netzweites Portnummerierungsschema ist ebenfalls möglich, wobei der Netzsteuerungsrechner weiß, wo (d. h. an welchem Standort) sich ein bestimmter Port zu einem bestimmten Zeitpunkt befindet.
Betrachten wir als Nächstes ein komplexeres Netz ohne gemeinsamen Mittelpunkt, weshalb die vom Netzsteuerungsrechner wahrgenommenen Funktionen auf die Netzknoten verteilt werden müssen. Im Rest dieses Abschnitts zeige ich, dass es möglich ist, die vom sternförmigen Netzsteuerungsrechner wahrgenommenen Funktionen auf effiziente und bequeme Weise auf die vielen Netzstandorte zu verteilen und weiterhin 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 einen verteilten Netzsteuerungsrechner tauglich zu machen. Zum RECEIVE wird ein Parameter hinzugefügt, der einen Standort angibt, an den das RECEIVE gesendet werden soll. Zu den Nachrichten SEND FROM ANY und SEND wird ein Standort hinzugefügt, an den das SEND gesendet werden soll, obwohl dies normalerweise der lokale Standort ist. Sowohl RECEIVE als auch RECEIVE ANY haben die Möglichkeit erhalten, den Quellstandort jeder empfangenen Nachricht zu erhalten. Wird somit ein RECEIVE ausgeführt, so 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 das SEND ausführenden Prozesses. An diesem Standort, Zusammenführungsstandort (rendezvous site) genannt, wird das RECEIVE mit dem richtigen SEND zur Deckung gebracht, und die Nachrichtenübertragung darf vom SEND-Standort zu dem Standort stattfinden, von dem das RECEIVE kam.
Ein RECEIVE ANY verlässt niemals seinen Ursprungsstandort, und darin liegt die Notwendigkeit von SEND FROM ANY, denn 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. Es ist möglich, ein System so zu bauen, dass die SEND/RECEIVE-Zusammenführung 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.
An jedem Standort wird eine Zusammenführungstabelle geführt. Diese Tabelle enthält einen Eintrag für jedes an diesem Standort empfangene, nicht zugeordnete SEND oder RECEIVE sowie einen Eintrag für alle an diesem Standort ausgegebenen RECEIVE ANYs. Ein zusammengehöriges SEND/RECEIVE-Paar wird aus der Tabelle gelöscht, sobald die Zuordnung erfolgt ist. Wie in der entsprechenden Tabelle im Modell-Time-Sharing-System 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 zur Verteilung der Funktionen des Netzsteuerungsrechners besteht darin, jedem Standort einen Teil der eindeutigen Nummern zu geben, die er über seine UNIQUE-Operation verteilt. Dieses Thema erörtere ich weiter unten.
Damit dem Leser klar wird, wie der verteilte Netzsteuerungsrechner arbeitet, folgt ein Beispiel. Die Einzelheiten, welcher Prozess Portnummern auswählt usw., sind nur beispielhaft und kein im Rahmen des IPC festgelegter Standard.
Angenommen, für zwei Standorte im Netz, K und L, möchte Prozess A am Standort K mit Prozess B am Standort L kommunizieren. Prozess B hat ein RECEIVE ANY auf Port M anhängig.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ / \ /
\ / RECEIVE--> port M /
\ / ANY \ /
\______/ \______/
Prozess A kennt glücklicherweise die Existenz von Port M am Standort L und sendet mittels der Operation SEND FROM ANY eine Nachricht von Port N an Port M. Die Nachricht enthält zwei Portnummern und Anweisungen für Prozess B, die Nachrichten für Prozess A von Port Q an Port P zu senden. Die Standortnummer von Standort K wird dieser Nachricht zusammen mit dem SEND-Port N der Nachricht angefügt.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port N / \ port M /
\ /--->SEND FROM --->\ /
\ / ANY \ /
\______/ \______/
to port M, site L
containing K,N,P, & Q
Prozess A führt nun ein RECEIVE auf Port P von Port Q aus. Prozess A gibt Standort L als Zusammenführungsstandort an.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | ^ | Process B |
| | | | |
\ port P / | \ /
\ / | \ /
\ / <--RECEIVE __/ \ /
\______/ MESSAGE \______/
to site L
containing P, Q, & K
Eine RECEIVE-Nachricht wird von Standort K an Standort L gesendet und in die Zusammenführungstabelle am Standort L eingetragen. Zu einem anderen Zeitpunkt führt Prozess B ein SEND auf Port P von Port Q aus und gibt Standort L als Zusammenführungsstandort an.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | | Process B |
| | | |
\ port P / <--------- port Q /
\ / \ /
\ / SEND \ /
\______/ \______/
to site L
containing P & Q
Eine Zusammenführung kommt zustande, die Zusammenführungstabelle wird gelöscht, und die Übertragung an Port P am Standort K findet statt. Die Standortnummer des SEND (und denkbar auch die SEND-Portnummer) wird den Nachrichten der Übertragung zur Erbauung des empfangenden Prozesses angefügt.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port P / \ port Q /
\ /<--transmission<--\ /
\ / \ /
\______/ to port P, site K \______/
containing data and L
Prozess B möchte gleichzeitig ein RECEIVE von Port N auf Port M ausführen.
Man beachte, dass es in diesem System nur eine wichtige Steuernachricht gibt, die zwischen Standorten wandert, nämlich die Art von Nachricht, die in [2] Host/Host-Protokollnachricht genannt wird. Diese Steuernachricht ist die RECEIVE-Nachricht. Es gibt zwei weitere mögliche Steuernachrichten zwischen Standorten: eine Fehlermeldung an den Ursprungsstandort, wenn ein RECEIVE oder SEND abläuft, und die SEND-Nachricht im seltenen Fall, dass der Zusammenführungsstandort nicht der SEND-Standort ist. Außerdem muss es ein Standardformat für Nachrichten zwischen Ports geben. Zum Beispiel das folgende:
_________________ __________________ _____________
| rendezvous site | <6> | destination site | | source site |
|-----------------| |------------------| |-------------|
| RECEIVE port | | RECEIVE port | | RECEIVE port|
|-----------------| |------------------| |-------------|
| SEND port | | SEND port | | SEND port |
|-----------------| |------------------| |-------------|
| | | source site | | |
| | |------------------| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|_________________| |__________________| |_____________|
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
Im Modell-Time-Sharing-System war es möglich, einen Port von Prozess zu Prozess weiterzugeben. Mit einem verteilten Netzsteuerungsrechner ist dies weiterhin möglich.
Man erinnere sich, dass zum Senden einer Nachricht von einem Prozess an einen anderen ein SEND auf Port M von Port N und ein RECEIVE auf Port M von Port N zusammenkommen müssen, normalerweise am SEND-Standort. Beide Prozesse führen Buch darüber, wo ihrer Meinung nach der Zusammenführungsstandort liegt, und liefern diesen Standort als Parameter der entsprechenden Operationen. Auch der RECEIVE-Prozess glaubt, der SEND-Standort zu sein. Da die Übertragung, sobald ein SEND und ein RECEIVE zusammenkommen, an die Quelle des RECEIVE gesendet wird und der Eintrag in der Zusammenführungstabelle gelöscht wird und für jede weitere Übertragung von N nach M neu angelegt werden muss, ist es einfach, einen RECEIVE-Port zu verschieben. Sendet ein Prozess sowohl die Portnummern als auch die Zusammenführungsstandortnummer an einen neuen Prozess an einem anderen Standort, der unter Verwendung dieser selben alten Portnummern und der Angabe des Zusammenführungsstandorts ein RECEIVE ausführt, so erfährt der Sender nie, dass der Empfänger umgezogen ist. Es ist etwas schwieriger, einen Sendport zu verschieben. Geschieht es jedoch, so werden das Paar von Portnummern, das für ein SEND verwendet wurde, und die ursprüngliche Zusammenführungsstandortnummer an den neuen Standort weitergegeben. Der Prozess am neuen SEND-Standort gibt beim ersten SEND vom neuen Standort den alten Zusammenführungsstandort an. Der RECEIVE-Prozess wird ebenfalls weiterhin glauben, der Zusammenführungsstandort sei der alte Standort, sodass SEND und RECEIVE sich am alten Standort treffen. Wenn sie sich treffen, wird der Eintrag in der Tabelle dieses Standorts gelöscht, und sowohl die SEND- als auch die RECEIVE-Nachricht werden an den neuen SEND-Standort gesendet, gerade als wären sie von Anfang an dorthin bestimmt gewesen. SEND und RECEIVE treffen sich dann erneut am neuen Zusammenführungsstandort, und die Übertragung kann fortgesetzt werden, als hätte sich der Port nie bewegt. Da alle Übertragungen die Quellstandortnummer enthalten, werden weitere RECEIVEs an den neuen Zusammenführungsstandort gesendet. Man kann erkennen, dass diese besondere Behandlung stattfinden muss, weil eine SEND-Nachricht an einem Standort empfangen wird, der die SEND-Nachricht nicht ausgelöst hat<7>. Man beachte, dass sich der SEND-Port und der RECEIVE-Port gleichzeitig verschieben können.
Natürlich hätte all dies auch geschehen können, wenn die Prozesse Nachrichten hin- und hergesendet hätten, die etwaige Verschiebungen und die neuen Standortnummern ankündigen.
Ein Problem, das dem Leser gekommen sein mag, ist die Frage, wie SEND- und RECEIVE-Puffer in ihrer Größe aufeinander abgestimmt werden. Die einfachste Lösung wäre zu verlangen, dass alle Puffer eine gemeinsame Größe haben, aber das ist unannehmbar, weil es sich nicht ohne Weiteres auf eine Lage erweitern lässt, in der Prozesse in autonomen Betriebssystemen zu kommunizieren versuchen. Eine zweite Lösung besteht darin, dass die Prozesse Nachrichten austauschen, die die Puffergrößen angeben. Wird diese Lösung gewählt, so werden übermäßige, vom SEND-Prozess gesendete Daten, die nicht in den RECEIVE-Puffer passen, verworfen und der RECEIVE-Prozess wird benachrichtigt. Diese Lösung ist wegen ihrer Einfachheit sehr ansprechend. Eine dritte Lösung wäre, die RECEIVE-Puffergröße mit der RECEIVE-Nachricht an den SEND-Standort weiterzugeben und den SEND-Prozess zu benachrichtigen, wenn zu viele Daten gesendet werden, oder sogar die RECEIVE-Puffergröße an den SEND-Prozess weiterzugeben. Diese letzte Methode würde es dem Netzsteuerungsrechner am SEND-Standort außerdem erlauben, aus einem SEND zwei oder mehr SENDs zu machen, wenn dies nötig wäre, um eine kleinere RECEIVE-Puffergröße zu bedienen.
Die Pflege der eindeutigen Nummern ist ebenfalls ein Problem, wenn die Prozesse geografisch verteilt sind. Hier werden drei Lösungen für dieses Problem vorgestellt. Die erste Möglichkeit besteht darin, dass die autonomen Betriebssysteme die eindeutigen Nummern ursprünglich beim Netzsteuerungsrechner anfordern und danach die Unversehrtheit aller eindeutigen Nummern gewährleisten, die sich gegenwärtig im Besitz lokaler Prozesse und Programme befinden, und zwar mit allen Mitteln, die dem Betriebssystem zur Verfügung stehen. In diesem Fall würde der Netzsteuerungsrechner ein Verfahren bereitstellen, mit dem eine eindeutige Nummer von einem Standort an einen anderen gesendet werden kann, und würde 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 dabei auf das nicht böswillige Verhalten der Prozesse zu vertrauen, um die eindeutigen Nummern zu bewahren, oder, falls ein Unfall geschieht, auf die beiden Kennwörter (SEND- und RECEIVE-Portnummern), die zum Einleiten einer Übertragung erforderlich sind. Werden die eindeutigen Nummern nicht fortlaufend ausgegeben und sind sie einigermaßen lang (sagen wir 32 Bit), so ist die Gefahr gering. Bei der letzten Methode wird eine Benutzerkennung in die Portnummern aufgenommen, und die einzelnen Betriebssysteme gewährleisten die Unversehrtheit 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 sogenannte Konzept des virtuellen Netzes (virtual net), das W. Crowther [2] vorgeschlagen hat.<8>
Ein drittes schwieriges Problem entsteht, wenn entfernte Prozesse kommunizieren wollen: das Problem, Verbindungen mit hoher Bandbreite zwischen den entfernten Prozessen aufrechtzuerhalten. Die Lösung dieses Problems liegt darin, den Prozessen erhebliche Informationen über den Zustand einer laufenden Übertragung zu geben. Zunächst betrachten wir einen SEND-Prozess im Einzelnen. Führt ein Prozess ein SEND aus, so gibt der lokale Teil des Netzsteuerungsrechners das SEND an den Zusammenführungsstandort weiter, normalerweise den lokalen Standort. Trifft ein zu einem anhängigen SEND passendes RECEIVE ein, so benachrichtigt der Netzsteuerungsrechner den SEND-Prozess, indem er eine Unterbrechung zur angegebenen Wiederaufnahmestelle auslöst. Gleichzeitig beginnt der Netzsteuerungsrechner, den SEND-Puffer an den RECEIVE-Standort zu versenden. Ist die Übertragung abgeschlossen, so wird ein Kennzeichen gesetzt, das der SEND-Prozess prüfen kann. Während eine Übertragung stattfindet, kann der Prozess den Netzsteuerungsrechner um die Ausführung anderer Operationen bitten, darunter weitere SENDs. Ein zweites SEND über ein bereits in Übertragung befindliches Portpaar wird vermerkt, und das SEND wird aktiv, sobald die erste Übertragung abgeschlossen ist. Ein drittes gleichartiges SEND führt zu einer Fehlermeldung an den sendenden Prozess. Als Nächstes betrachten wir einen RECEIVE-Prozess im Einzelnen. Führt ein Prozess ein RECEIVE aus, so wird das RECEIVE an den Zusammenführungsstandort gesendet. Wenn die aus diesem RECEIVE hervorgegangenen Daten am RECEIVE-Standort einzutreffen beginnen, wird der RECEIVE-Prozess über eine Unterbrechung zur angegebenen Wiederaufnahmestelle benachrichtigt. Ist die Übertragung abgeschlossen, so wird ein Kennzeichen gesetzt, das der RECEIVE-Prozess prüfen kann. Ein zweites RECEIVE über dasselbe Portpaar ist zulässig. Ein drittes führt zu einer Fehlermeldung an den RECEIVE-Prozess. Somit gibt es ausreichende Mechanismen, damit ein Prozesspaar stets sowohl eine laufende Übertragung als auch die nächste anhängige haben kann. Es geht daher keine Effizienz verloren. Andererseits muss jeder Übertragung ein RECEIVE in einen angegebenen Puffer vorausgehen, wodurch weiterhin eine vollständige Flusssteuerung gegeben ist.