DE3688893T2

DE3688893T2 - Datentransfer und Puffersteuerung mit mehrfachen prozesstransparenten Speicherbetriebsarten.

Info

Publication number: DE3688893T2
Application number: DE86107010T
Authority: DE
Inventors: Walter Henry Schwane; Frederick Joseph Ziecina
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1985-06-17
Filing date: 1986-05-23
Publication date: 1994-03-17
Anticipated expiration: 2006-05-24
Also published as: EP0205945B1; EP0205945A3; CA1244555A; JPS61289458A; JPH03659B2; DE3688893D1; EP0205945A2; US4937737A; ES8802094A1; ES556089A0

Description

Die Erfindung bezieht sich auf eine Datenübertragungseinrichtung mit mehreren Speichermodi und genauer auf die unabhängige und transparente Wahl des Speichermodus durch Kommunikationsprozesse.
In einem verteilten Rechensystem können Prozesse, die miteinander zum Zwecke des Datenzugriffs kommunizieren, physisch voneinander getrennt sein. Das heißt, sie befinden sich in verschiedenen Prozessoren des verteilten Systems und werden in diesen ausgeführt oder verwenden keinen gemeinsamen Speicher. Ein Prozeß, der in einem Prozessor des Systems zu einem bestimmten Zeitpunkt ausgeführt wird, kann in einem anderen Prozessor des Systems zu einem späteren Zeitpunkt ausgeführt werden. Beispielsweise kann ein Prozeß in einem anderen Prozessor ausgeführt werden, um die Belastung des Systems auf die Prozessoren, aus denen das System besteht, zu verteilen.
Wenn ein Prozeß von einem Prozessor auf einen anderen verlagert wird, ist es wünschenswert, den Umfang des erforderlichen Neuentwurfs zu minimieren. Prozesse werden typischerweise so entworfen, daß sie bestimmte Annahmen über die physische Position der Prozesse, mit denen sie kommunizieren möchten, in sich tragen.
Dies ist der Fall, wenn bei der Kommunikation mit einem anderen Prozeß zum Zwecke des Datenzugriffs Speichermodi für das Übertragen und Lokalisieren (Locate) verwendet werden. Beim Modus "Locate" werden keine Daten in den Speicher eines Prozesses übertragen, der die Daten anfordert: Es wird ein Zeiger geliefert, der auf die Daten im Speicher verweist, die für den anfordernden Prozeß verfügbar sind. Im Übertragungsmodus werden Daten in einen Speicherbereich versetzt, der vom anfordernden Prozeß angegeben wurde.
Bei der traditionellen Verwendung des Locate-Modus wird davon ausgegangen, daß der Prozeß, der einen Zeiger auf die Daten zur Verfügung stellt, denselben Speicher wie der anfordernde Prozeß gemeinsam nutzt. Wenn einer der Prozesse in einen anderen Prozessor übertragen wird oder den Speicher nicht mehr gemeinsam nutzt, ist der Locate-Modus nicht mehr funktionsfähig, und für die Auswahl eines anderen Zugriffsmodus ist eine Entwurfsänderung erforderlich.
Im IBM Technical Disclosure Bulletin Vol. 23 No. 5, Oktober 1980, Distributed Data Processing System, wird ein Verarbeitungssystem beschrieben, in dem die Systemressourcen zu Prozessen gehören und die Kommunikation zwischen Prozessen indirekt über Supervisor-Dienste erfolgt. Hierdurch wird eine gewisse Prozeßmobilität bewirkt. Die Kommunikation erfolgt in Form von Nachrichten, die von den Kommunikationseinrichtungen der Subsysteme verarbeitet werden. Im IBM Technical Disclosure Bulletin Vol. 22 No. 7, Dezember 1979, Message-Based Protocol for Interprocessor Communication, wird ein nachrichtengestütztes Protokoll für die Kommunikation zwischen Prozessen vorgestellt, die auf verschiedenen Prozessoren ausgeführt werden, die über einen gemeinsamen Bus lose gekoppelt sind. Die Prozesse sind als Ausführungseinheiten definiert, die über Nachrichten-Warteschlangen und über gemeinsam genutzte Variable Interaktionen durchführen.
Ein Prozeß, der auf Daten zugreift, kann Pufferbereiche angeben, in welche die angeforderte Daten gestellt werden sollen oder aus denen Daten abgesendet werden sollen. Diese Puffer werden dynamisch zugewiesen und von dem Prozeß gesteuert, der auf die Daten zugreift. Wenn die Kontrolle dieser Puffer an einen anderen Prozeß übergeben werden soll, müssen diese beiden Prozesse zum Zeitpunkt ihres Entwurfes Konventionen für die Übergabe der Kontrolle vereinbaren.
Die Übergabe der Kontrolle von dynamisch zugewiesenen Puffern zwischen Prozessen ist ein weiterer Fall, in dem eine Entwurfsänderung erforderlich ist, wenn einer der Prozesse in einen anderen Prozessor übertragen wird.
Die US-Patentschrift A-4 396 983 stellt eine Prozeßkommunikationseinrichtung in einem verteilten Prozessorsystem vor, wobei jeder Prozessor über Speicherverwaltungsdienste verfügt, die Prozeßkommunikationseinrichtung die Kommunikation zwischen mindestens zwei Prozessen durchführt, die sich in verschiedenen Prozessoren befinden können, die Einrichtung eine Mehrzahl verschiedener Datenübertragungsmodi unterstützt, deren Auswahl von den Prozessen gesteuert wird, die Einrichtung an jedem Prozessor einerseits ein mit jedem Prozeß gekoppeltes Prozeßschnittstellenmittel beinhaltet, durch das jeder kommunizierende Prozeß Datenübertragungsmodi wählt, die von den durch die anderen kommunizierenden Prozesse gewählten Datenübertragungsmodi unabhängig sind, und andererseits ein Steuermittel für den Datenzugriff, das mit dem Prozeßschnittstellenmittel und den Speicherverwaltungsdiensten für die Steuerung der Speicherverwaltungsdienste in Abhängigkeit von den durch die Kommunikationsprozesse gewählten Übertragungsmodi gekoppelt ist.
Die Aufgabe der Erfindung ist die Verbesserung einer derartigen Prozeßkommunikationseinrichtung.
Eine Prozeßkommunikationseinrichtung in einem verteilten Prozessorsystem gemäß der Erfindung ist dadurch gekennzeichnet, daß diese Steuermittel für den Datenzugriff mindestens einen ersten Datenübertragungsmodus unterstützen, in dem die zu übertragenden Daten zwischen dem sendenden und dem empfangenden Prozeß kopiert werden, und einen zweiten Modus, in dem nur ein Zeiger auf die Daten übergeben wird; daß die Steuermittel für den Datenzugriff weiterhin ein zusätzliches Versetzen oder Kopieren der Daten zumindest dann durchführen, wenn vom sendenden Prozeß der zweite Modus festgelegt wurde und kein gemeinsamer Speicher verfügbar ist oder wenn der sendende Prozeß einen der beiden Modi festgelegt hat, der empfangende Prozeß aber den anderen; und daß das Steuermittel für den Datenzugriff die von den lokalen Betriebssystemen jedes Prozessors zur Verfügung gestellten Speicherverwaltungsdienste verwendet und keine eigenen Speicherverwaltungsdienste bietet.
Eine Prozeßkommunikationseinrichtung in einem Prozessorsystem ermöglicht die Datenkommunikation zwischen mindestens zwei Prozessen. Die Einrichtung unterstützt eine Mehrzahl verschiedener Datenübertragungsmodi, die von Speicherverwaltungsdiensten des Prozessors oder der Prozessoren zur Verfügung gestellt werden. Ein Prozeßschnittstellenmittel bietet eine gemeinsame Verbsyntax, mit der jeder kommunizierende Prozeß Datenübertragungsmodi unabhängig von dem durch den anderen kommunizierenden Prozeß gewählten Datenübertragungsmodus auswählen kann. Eine Steuerfunktion für den Datenzugriff ist mit dem Prozeßschnittstellenmittel und den Speicherverwaltungsdiensten gekoppelt. Die Steuerfunktion für den Datenzugriff steuert die Verwendung der Speicherverwaltungsdienste in Abhängigkeit von den durch die kommunizierenden Prozesse gewählten Übertragungsmodi. Für die Prozesse ist es transparent, welcher Übertragungsmodus vom jeweils anderen Prozeß gewählt wurde.
Daten werden durch einen Transportmechanismus übertragen, der einen Datenpfad zwischen Prozessen unabhängig davon bildet, ob sich die Prozesse in demselben Prozessor oder in verschiedenen Prozessoren befinden. Die Optionen für den Datenübertragungsmodus zur Handhabung und Verwaltung von Sendedaten und Empfangsdaten sind MOVE, PASS, LOCATE und GETBUF/FREEBUF.
Im Modus MOVE (Übertragen) erhält der Empfänger eine Kopie der Informationen; jeder kommunizierende Prozeß verfügt stets über eine eigene Kopie der Informationen und hat keine Kenntnis davon, wie der andere Prozeß seine Kopie der Daten verwendet. Im Modus PASS (Übergeben) kann ein Prozeß die Steuerfunktion für den Datenzugriff veranlassen, eine Zwischenkopie der gesendeten Daten anzufertigen, so daß der Speicher des Senders sofort wieder genutzt werden dann. Im Modus LOCATE (Lokalisieren) übergibt, wenn kommunizierende Programme Zugriff auf gemeinsam genutzten Speicher haben, die Steuerfunktion für den Datenzugriff einen Zeiger auf die Daten, und die Daten selbst werden nicht übertragen. Wenn die Programme keinen Zugriff auf gemeinsam genutzten Speicher haben, liefert die Steuerfunktion für den Datenzugriff eine Kopie der im Speicher befindlichen Daten, auf die der Empfänger der Daten Zugriff hat.
FREEBUF (Puffer freigeben) gestattet es einem Datenabsender, die Zuständigkeit für die Pufferverwaltung an einen Empfänger zu übergeben, der GETBUF (Puffer anfordern) festlegt. Wenn Sender und Empfänger Zugriff auf gemeinsam genutzten Speicher haben, fällt die Übertragung von Daten weg. Wenn die Prozesse keinen Zugriff auf gemeinsam genutzten Speicher haben, liefert die Steuerfunktion für den Datenzugriff eine Kopie der Puffer an den Empfänger.
Jeder der kommunizierenden Prozesse kann den von ihm gewünschten Datenübertragungsmodus verwenden, ohne den von den anderen Prozessen verwendeten Modus beachten zu müssen. Die Steuerfunktion für den Datenzugriff führt zusätzliche Datenübertragungen oder Datenkopiervorgänge, die unter Umständen erforderlich sind, ohne besondere Mitwirkung von Seiten der kommunizierenden Programme durch. So kann das Übertragen von Daten durch die Steuerfunktion für den Datenzugriff die Übertragung von Daten über ein physisches Transportmittel wie einen Bus von einem Prozessor zum anderen erfordern. Für diese Programme bleiben die jeweiligen Positionen transparent, während gleichzeitig die möglichen Leistungsvorteile zur Verfügung stehen, die sich bei Verwendung dieser Modi ergeben, wenn gemeinsam genutzter Speicher verfügbar ist.
Die Steuerfunktion für den Datenzugriff bietet keine Speicher- oder Pufferverwaltungsdienste. Sie verwendet die Speicherverwaltungseinrichtungen, die vom lokalen Betriebssystem zur Verfügung gestellt werden. Diese Einrichtungen werden verwendet, um Speicher für die Verwendung mit den Modi LOCATE und GETBUF/FREEBUF nach Bedarf zuzuordnen und freizugeben. Dadurch können Prozesse leicht an unterschiedliche Positionen innerhalb desselben Prozessors oder zwischen verschiedenen Prozessoren übertragen werden, ohne daß eine Entwurfsänderung erforderlich ist.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm mit einer Übersicht über ein Mehrprozeßsystem, das über eine Prozeßkommunikationseinrichtung für die Kommunikation zwischen Prozessen verfügt;
Fig. 2 ist eine schematische Darstellung von zwei Prozessen, die über die Prozeßkommunikationseinrichtung von Fig. 1 kommunizieren;
Fig. 3 ist eine schematische Darstellung eines Prozesses, der über die Prozeßkommunikationseinrichtung von Fig. 1 Daten von einem Diskettensteuerprozeß empfängt;
Fig. 4 ist eine schematische Darstellung eines Prozesses, der über die Prozeßkommunikationseinrichtung von Fig. 1 Daten an einen Diskettensteuerprozeß überträgt;
Fig. 5 ist eine schematische Darstellung eines Typs eines Datenübertragungsmodus, der von einem Prozeß für die Kommunikation mit einem anderen Prozeß über die Prozeßkommunikationseinrichtung von Fig. 1 gewählt wird;
Fig. 6 ist eine schematische Darstellung eines weiteren Typs eines Datenübertragungsmodus, der von Prozessen für die Kommunikation mit einem anderen Prozeß über die Prozeßkommunikationseinrichtung von Fig. 1 gewählt wird;
Fig. 7 ist ein Blockdiagramm eines Deskriptorelements, das von der Prozeßkommunikationseinrichtung von Fig. 1 zur Identifizierung von Speicherbereichen verwendet wird;
Fig. 8 ist ein Blockdiagramm einer Datenreferenzierung unter Verwendung der Prozeßkommunikationseinrichtung von Fig. 1;
Fig. 9 ist ein Blockdiagramm von Deskriptorelementen, die von der Prozeßkommunikationseinrichtung von Fig. 1 zur Bezeichnung von Speicherpositionen von Datensegmenten verwendet werden;
Fig. 10 ist ein Blockdiagramm eines verteilten Datenstroms;
Fig. 11 ist ein Blockdiagramm der Segmentierung eines verteilten Datenstroms zur Bildung neuer verteilter Datenströme;
Fig. 12 ist ein Syntaxdiagramm eines Verbs für das Senden einer Anforderung, das von Prozessen für den Kontakt mit der Prozeßkommunikationseinrichtung von Fig. 1 verwendet wird;
Fig. 13 ist ein Syntaxdiagramm eines Verbs für das Senden einer Antwort, das von Prozessen für den Kontakt mit der Prozeßkommunikationseinrichtung von Fig. 1 verwendet wird;
Fig. 14 ist ein Syntaxdiagramm eines Verbs für den Empfang einer Warteschlange, das von Prozessen für den Kontakt mit der Prozeßkommunikationseinrichtung von Fig. 1 verwendet wird;
Fig. 15 ist ein Syntaxdiagramm eines Verbs für den Empfang einer Anforderung, das von Prozessen für den Kontakt mit der Prozeßkommunikationseinrichtung von Fig. 1 verwendet wird;
Fig. 16 ist ein Syntaxdiagramm eines Verbs für den Empfang von Daten, das von Prozessen für den Kontakt mit der Prozeßkommunikationseinrichtung von Fig. 1 verwendet wird.

Ausführliche Beschreibung der bevorzugten Anwendungsform

In Fig. 1 ist die Detailansicht einer verteilten Prozeßumgebung allgemein mit 10 bezeichnet. Ein mit 12 bezeichneter Prozessor A ist über einen physischen Pfad, der als Leitung 14 dargestellt ist, mit einem mit 16 bezeichneten Prozessor B gekoppelt. Prozessor A enthält in der Darstellung einen mit 18 bezeichneten Prozeß A sowie einen mit 19 bezeichneten, ebenfalls dort befindlichen Prozeß B. Ein Speicherbereich 20 ist Prozeß A und Prozeß B zugeordnet, wie durch die Leitungen 21 bzw. 22 dargestellt, um den Prozessen die Steuerung des Datenspeichers und den Zugriff darauf zu ermöglichen.
Prozessor B enthält in der Darstellung einen mit 23 bezeichneten Prozeß C und einen mit 24 bezeichneten, ebenfalls dort befindlichen Prozeß D. Ein Speicherbereich 25 ist Prozeß C und Prozeß D zugeordnet, wie durch die Leitungen 26 bzw. 28 dargestellt, um den Prozessen die Steuerung des Datenspeichers und den Zugriff darauf zu ermöglichen.
Prozesse oder ausgeführte Programme innerhalb der Prozessoren müssen miteinander kommunizieren. In Prozessoren unterschiedlicher Konfiguration oder auch in demselben Prozessor über einen gewissen Zeitraum können sich zwei kommunizierende Prozesse an verschiedenen Positionen zueinander befinden und verschiedene physische Pfade zwischen sich haben.
Eine Prozeßkommunikationseinrichtung (Inter Process Communication Facility - IPCF) befindet sich in Prozessor A und Prozessor B bei 30 bzw. 32, um eine Prozeßkommunikation durchzuführen, die für die kommunizierenden Prozesse hinsichtlich der Positionen transparent ist. Die IPCF 30 ist mit Prozeß A in Prozessor A gekoppelt, wie durch Leitung 34 dargestellt, und mit Prozeß B, wie durch Leitung 36 dargestellt. Leitungen 34 und 36 bilden Schnittstellen zwischen Prozeß A und Prozeß B einerseits und der IPCF 30 andererseits. Diese Schnittstellen gestatten die Kommunikation zwischen Prozeß A und Prozeß B, sofern entsprechende Datenpfade aufgebaut wurden. IPCF 30 ist außerdem durch einen Transportmechanismus 38 über Leitung 14 und durch einen Transportmechanismus 40 in Prozessor B mit IPCF 32 gekoppelt. IPCF 32 ist wiederum über die mit 42 und 44 bezeichneten Schnittstellenleitungen mit Prozeß C und Prozeß D gekoppelt. Diese Schnittstellen ermöglichen gemeinsam mit den IPCFs und den Transportmechanismen den Aufbau einer Kommunikation zwischen allen angegebenen Prozessen, ohne daß einer der Prozesse die Position des Prozesses kennt, mit dem er kommuniziert.
Die Transportmechanismen 38 und 40 beinhalten vorzugsweise eine Mehrzahl von Transportmechanismen, beispielsweise lokale Transportmechanismen, die verwendet werden, wenn Prozeß A und Prozeß B oder Prozeß C und Prozeß D innerhalb eines einzelnen Prozessors miteinander kommunizieren. Wenn sich Prozessor A und Prozessor B in derselben Maschine befinden, wird ein Bus-Transportmechanismus verwendet, um die Kommunikation zwischen Prozessen auf Prozessor A und Prozessor B zu ermöglichen. Für die Kommunikation zwischen verschiedenen Maschinen ist ein Kommunikationsprotokoll wie SNA geeignet.
Die Transportmechanismen 38 und 40 dienen zum Übertragen von Daten. Sie sind dafür zuständig, Datenbytes von einer Stelle an eine andere zu übertragen, ohne die Bedeutung der übertragenen Informationen zu verstehen. Somit ist Speicher 20 in Prozessor A mit dem Transportmechanismus 38 über eine mit 46 bezeichnete Leitung gekoppelt, und Speicher 25 in Prozessor B ist mit Transportmechanismus 40 durch eine mit 48 bezeichnete Leitung gekoppelt, so daß die Übertragung von Informationen direkt durch die Transportmechanismen 38 und 40 möglich ist.
Die IPCF des Prozesses, der einen Kommunikationsversuch durchführt, wählt den Transportmechanismus für die Kommunikation aus. Die kommunizierenden Prozesse müssen keine Kenntnis von dem verwendeten Mechanismus haben. Der Prozeß, der einen Kommunikationsversuch durchführt, liefert den Namen des Zielprozesses in der Form, wie er dem Prozeß, der den Kommunikationsversuch durchführt, bekannt ist, an die IPCF, die zur Lokalisierung einen geeigneten Verzeichnisdienst verwendet. Die IPCF wählt dann den geeigneten Transportmechanismus und verwendet vom System bereitgestellte Dienste, um die Verbindung zwischen den Prozessen nach einem standardisierten Verfahren aufzubauen. Die IPCF kann von Prozessen aller Ebenen, von Anwendungsprogrammen bis hin zu elementaren Systemdiensten wie einem Seitenwechselverwalter, verwendet werden.
Damit die Verwendung vieler verschiedener Transportmechanismen möglich ist, die jeweils unterschiedliche Fähigkeiten und Eigenschaften besitzen, enthält die IPCF für jeden Prozeß eine allgemeine Schnittstelle zum Transportmechanismus. Die Schnittstelle definiert einen Satz von Funktionen für den Aufbau von Verbindungen und für die Übergabe von Informationen zwischen Prozessen. Die von der IPCF verwendeten Transportmechanismen sind mit den definierten Funktionen maskiert. Für die Schnittstelle geschriebene Programme sind bei der Kommunikation vom Transportmechanismus und daher auch von ihrer jeweiligen Position unabhängig.
Die Kommunikation zwischen Prozessen erfolgt als Senden und Empfangen von Nachrichten über eine von der IPCF zwischen ihnen aufgebaute Verbindung. Die Nachrichten enthalten Arbeitsanforderungen und/oder Daten. In bezug auf eine bestimmte Arbeitsanforderung übernimmt ein Prozeß entweder die Rolle eines Requestors oder die eines Servers. Der Requestor löst eine Arbeitsanforderung aus, indem er eine Anforderung an einen Server sendet, der sie dann ausführt. Anforderungen enthalten eine Arbeitsanforderung (einen Befehl und seine Parameter) und wahlweise einige Daten. Sowohl die Anforderung als auch die Daten haben variable Länge.
In Fig. 2, einer schematischen Darstellung zweier kommunizierender Prozesse, ist die Absendung einer Arbeitsanforderung durch einen Requestorprozeß 50 und die Bearbeitung der Arbeitsanforderung durch einen Serverprozeß 52 in Form von in aufsteigender Folge numerierten Schritten dargestellt. Eine Verbindung zwischen Requestorprozeß 50 und Serverprozeß 52 wurde von der IPCF und dem allgemein mit 53 bezeichneten Transportmechanismus bereits aufgebaut. Jedem Prozeß ist eine Warteschlange zugeordnet, die zur Einreihung von Hinweisen verwendet wird; dies sind kleine Datenpakete, die von anderen Prozessen aufgegebene Arbeitsanforderungen vertreten. Für Prozeß 50 wird von seiner lokalen IPCF 55 eine Warteschlange 54 bereitgestellt, für Prozeß 52 wird von seiner lokalen IPCF 57 eine Warteschlange 56 bereitgestellt.
Der Reguestorprozeß 50 bereitet die Arbeitsanforderung vor, die im Requestorspeicher 58 gespeichert wird. Der Requestorprozeß 50 bereitet außerdem ein IPCF-Verb vor, das mit "Send Request" (1) bezeichnet ist. Das Verb "Send Request" wird vom Prozeß verwendet, um der IPCF 55 anzuzeigen, daß eine Arbeitsanforderung für die Bearbeitung durch einen anderen Prozeß vorbereitet wurde. Es enthält Informationen (der Inhalt von IPCF-Verben wird später beschrieben), aus denen die für Server 52 lokale IPCF 57 einen Hinweis eines bestimmten Typs ableitet. Dieser Hinweis wird als Anforderungshinweis bezeichnet und enthält Informationen wie die Identität des Absenders, die Länge der Anforderung und eine eindeutige Anforderungskennung (Request ID - Rid), die als Token die Arbeitsanforderung eindeutig bezeichnet.
Datenstrukturen werden über den Transportmechanismus gesendet und enthalten Informationen, aus denen der Hinweis abgeleitet wird. Die Datenstrukturen geben die Anforderungskennung an, sowie eine Verbindungskennung, die den Serverprozeß bezeichnet, eine Anforderungspriorität und Deskriptorelemente. Jedes Deskriptorelement beschreibt ein zusammenhängendes Stück des realen Speichers und bezeichnet an den Server zu übertragende Daten oder Speicher für an den Requestor zu übertragende Daten. Jedes Deskriptorelement gibt außerdem die Prozessoradresse an, die das Speicherstück, die Speicheradresse und die Länge des Speicherstücks enthält.
Der Hinweis, der aus der die Arbeitsanforderung darstellenden Datenstruktur abgeleitet wurde, wird von der für Server 52 lokalen IPCF 57 in Warteschlange 56 gestellt (2). Wenn Server 52 bereit ist, mehr Arbeit aufzunehmen, setzt er ein Verb "Receive Queuell ab (3), um den Hinweis zu empfangen. Der Server 52 weist dann durch ein Verb "Receive Request" (4), das die Anforderungskennung referenziert, die IPCF 57 darauf hin, daß er zumindest einen Teil der Arbeitsanforderung empfangen möchte. IPCF 57 und der Transportmechanismus 53 übertragen dann die gewünschten Teile der Arbeitsanforderung aus Speicher 58 in Speicher 60, ohne daß Reguestor 50 beteiligt ist. Die Arbeitsanforderung ist dann für Server 52 direkt verfügbar.
Die Arbeitsanforderung enthält den eigentlichen Befehl und eventuell vorhandene Parameter. An dieser Stelle kann der Server 52 die Anforderung verarbeiten oder in seiner Eingangswarteschlange nach weiterer Arbeit suchen. Die Daten von Requestor 50 werden nach Bedarf empfangen. Nicht alle Daten müssen gleichzeitig empfangen werden. Für den Empfang der einer bestimmten Anforderung zugeordneten Daten liefert der Server der IPCF 57 die zugehörige Anforderungskennung in einem Verb "Receive Data" (5). Die angegebenen Daten werden dann von der IPCF und dem Transportmechanismus an Speicher 60 übertragen.
Daten, die von Server 52 an den Requestor 50 geliefert werden sollen, werden mit Hilfe eines Verbs "Send Response" (6) an die IPCF 57 in Server 52 gesendet. Die Daten werden dann von IPCF 57 und dem Transportmechanismus direkt in den Requestorspeicher 58 übertragen. Wenn Server 52 die Bearbeitung der Arbeitsanforderung abgeschlossen hat und alle Daten übertragen worden sind, liefert Server 52 ein abschließendes Verb "Send Response" mit Status (7) an die IPCF 57, die Datenstrukturen an die für Reguestor 50 lokale IPCF 55 überträgt, die wiederum einen Antworthinweis erzeugt, der in die Warteschlange 54 des Requestors 50 gestellt wird. Der Antworthinweis zeigt dem Reguestor 50 an, daß die Arbeitsanforderung abgeschlossen wurde und aus dieser Arbeitsanforderung resultierende Daten verfügbar sind.
Die ausschließliche Verwendung von Hinweisen in den Warteschlangen ermöglicht es, auf einfache Weise komplexe Handhabungsmuster für Anforderungswarteschlangen zu implementieren. Da Hinweise im Vergleich zum Gesamtumfang der Anforderungsdaten klein sind, können sie leicht umgeordnet werden. Dies gestattet es, Anforderungen eine Priorität zuzuordnen. Ein Server kann Anforderungen mit hoher Priorität bearbeiten und ist nicht gezwungen, Anforderungen nur in der Sendereihenfolge aus der Warteschlange zu entnehmen. Durch geschlüsselten Datenempfang aus der Warteschlange wird es ermöglicht, daß die Server einen Hinweis nur dann empfangen, wenn er über eine bestimmte Verbindung eingegangen ist.

ÜBERSICHT DER VERBEN

In der folgenden Liste sind die Verben mit ihren Funktionen aufgeführt, die von den Prozessen für den Kontakt mit der IPCF verwendet werden, um die IPCF Informationen an andere Prozesse übertragen zu lassen. Die Verben werden in einem der folgenden Abschnitte ausführlicher beschrieben.
Open (Öffnen) Eine IPCF-Verbindung zwischen zwei Prozessen aufbauen
Close (Schließen) Die IPCF-Verbindung zwischen zwei Prozessen trennen.
Specify Storage Pool (Speicherpool festlegen) Einen Speicherpool für die IPCF definieren, der von mehreren Prozessen gemeinsam genutzt werden kann. Durch die Verwendung eines Speicherpools kann die Notwendigkeit wegfallen, zwischen den Prozessen gesendete Daten tatsächlich zu übertragen oder zu kopieren.
Send Request (Anforderung senden) Eine Arbeitsanforderung absetzen. Der Prozeß, der die Arbeitsanforderung absetzt, ist der Requestor. Der Prozeß, an den die Anforderung gesendet wird, ist der Server.
Send Response (Antwort senden) Daten sowie wahlweise einen Status an einen Reguestor liefern.
Receive Queue (Warteschlange empfangen) Einen Hinweis aus der Prozeß-Eingangswarteschlange empfangen.
Receive Request (Anforderung empfangen) Eine von einem Requestor gesendete Arbeitsanforderung empfangen.
Receive Data (Daten empfangen) Die von einem Requestor gesendeten Daten empfangen.
Signal (Signalisieren) Einen Signalhinweis an einen anderen Prozeß senden.
Terminate Request (Anforderung beenden) Die Verarbeitung einer ausstehenden Anforderung oder aller ausstehenden Anforderungen einer Verbindung abbrechen.
Viele IPCF-Verben erzeugen Hinweise, die an die Warteschlange des jeweils anderen kommunizierenden Prozesses gesendet werden. Ein Hinweis "Request" (Anforderung) wird in die Eingangswarteschlange eines Prozesses gestellt, wenn der Prozeß das Ziel des Verbs "Send Request" eines anderen Prozesses ist. Ein Hinweis "Response" (Antwort) wird in die Eingangswarteschlange eines Prozesses gestellt, wenn ein anderer Prozeß ein Verb "Send Response", mit Beendigungsstatus ausführt.
Ein Hinweis "Signal" (Signal) wird in die Eingangswarteschlange eines Prozesses gestellt, wenn er das Ziel des "Signal" eines anderen Prozesses ist. "Signal"-Hinweise werden zur Versendung kleiner Datenmengen zwischen zwei Prozessen verwendet und enthalten die eigentlichen zu sendenden Daten.
Ein Hinweis "Open" (Öffnen) wird in die Eingangswarteschlange eines Prozesses gestellt, wenn auf Anforderung eines anderen Prozesses eine Verbindung zu ihm aufgebaut wurde, und ein Hinweis "Close" (Schließen) wird in die Eingangswarteschlange eines Prozesses gestellt, wenn eine Verbindung zu ihm durch einen anderen Prozeß abgebrochen werden soll oder abgebrochen wurde. Der Prozeß, der das Verb "Close" abgesetzt hat, erhält keinen Hinweis "Close" als Benachrichtigung, daß eine Verbindung unterbrochen werden soll, sondern erhält einen Hinweis "Close" als Benachrichtigung, daß "Close" abgeschlossen wurde.
Ein Hinweis "Terminate Request" (Anforderung beenden) wird in die Eingangswarteschlange eines Servers gestellt, wenn der Requestor eine ausstehende Anforderung beendet.
In der empfohlenen Anwendungsform werden die Hinweise in der folgenden Reihenfolge in die Eingangswarteschlangen gestellt, wobei 1 am Anfang der Warteschlange steht:
1. Terminate Request 2. Close 3. Open 4. Signal 5. Request und Response (in der Reihenfolge der Priorität)
Das Verb "Receive Queue" gestattet die Verwendung eines Schlüssels, der einschränkt, welche Hinweistypen den Anforderungen für den Empfang genügen. Mit Hilfe des Schlüssels wird festgelegt, ob der Empfang der Hinweise von ihrem Typ und von ihrer Herkunft (über welche Verbindung der jeweilige Hinweis empfangen wurde) abhängen soll.

BEISPIELE FÜR LESE- UND SCHREIBVORGÄNGE

Ein Lesevorgang ist in Fig. 3 dargestellt. Ein Requestor-Prozeß 70 wünscht, Daten von einem Server-Prozeß 72 zu lesen, der in diesem Beispiel ein Gerätesteuerprogramm für ein Diskettenlaufwerk ist. Von Requestor 70 wird an die lokale IPCF 73 ein Verb "Send Request" ausgegeben (1), das die Verbindungskennung (Connection ID - CID) 123 sowie den Anforderungstyp (Lesebefehl) enthält und einen Eingangsdatenbereich von zwei Vier-Kilobyte- Bereichen angibt. Weder die IPCF noch der allgemein mit 74 bezeichnete Transportmechanismus kennen den Inhalt der Anforderung. Das Format und der Inhalt der Anforderung (Lesebefehl) sind zwischen dem Requestor 70 und dem Server 72 vereinbart. Die IPCF zeigt an (2), daß das Verb für die Sendeanforderung abgeschlossen und mit der Anforderungskennung (Request ID - REQUID) 1 versehen wurde.
Eine Datenstruktur wird über Transportmechanismus 74 an die IPCF 75 des Servers 72 gesendet (3). Die für Server 72 lokale IPCF 75 leitet daraus einen Hinweis ab, der in eine dem Server 72 zugeordnete Warteschlange gestellt wird. Der Server 72 setzt ein Verb "Receive Queue" (4) ab und empfängt den Anforderungshinweis (5) und seine Verbindungskennung 45 sowie die Anforderungskennung 1 und eine Angabe über die Anforderungslänge. Sofern gewünscht, bereitet Server 72 ein Verb "Receive Request" vor (6), das die Anforderungskennung und die Beschreibung angibt. Die IPCF liefert die Arbeitsanforderung ohne Interaktion mit dem Requestor 70 (7).
Server 72 bereitet anschließend eine Sequenz von 16 Verben "Send Response" vor (die jeweils 512 zu schreibende Byte bezeichnen), von denen jedes die Anforderungskennung und 512 Byte der angeforderten Daten in der Arbeitsanforderung enthält. Die IPCF und der Transportmechanismus 74 stellen dann die Daten in den Speicher, der vom Requestor in der ursprünglichen Arbeitsanforderung angegeben wurde. Server 72 empfängt daraufhin einen Rückkehrcode (9), sobald jedes einzelne Verb "Send Response" abgeschlossen wurde, und bereitet ein abschließendes Verb "Send Response" vor (10), das die Anforderungskennung und den Status der Arbeitsanforderung enthält. Der Server empfängt dann eine Mitteilung, daß das Verb abgearbeitet wurde (11), und ein Antworthinweis wird an Requestor 70 gesendet (12). Requestor 70 gibt ein Verb "Receive Queue" mit einem Schlüssel aus (13), der Antworthinweise anfordert und wahlweise Anforderungskennung 1 angibt. Der Antworthinweis wird empfangen (14), der den Ausführungsstatus für Anforderungskennung 1 anzeigt.
Ein in Fig. 4 dargestellter Schreibvorgang wird auf sehr ähnliche Weise zwischen einem Requestor 80 und einem Server 82 durchgeführt. Der Requestor bereitet ein Verb "Send Request" vor (1), das dieses Mal den Ausgangsdatenbereich festlegt; das heißt, es werden zwei Vier-Kilobyte-Bereiche geschrieben. Die für den Requestor 80 lokale IPCF 83 zeigt den Abschluß des Verbs mit der Anforderungskennung 1 an (2). Der Anforderungshinweis wird in die Server-Warteschlange (3) und das von Server 82 abgesetzte Verb "Receive Queue" gestellt (4). Der Anforderungshinweis wird von Server 82 empfangen (5), und ein Verb "Receive Request" wird an die für Server 82 lokale IPCF 85 gesendet (6). Die vom Verb "Receive Request" angegebene Arbeitsanforderung wird dann von der IPCF und vom Transportmechanismus 84 geliefert (7). Ein Verb "Receive Data" (8) entsteht, wenn der Server 82 die Arbeitsanforderung ausführt, und wird an die IPCF übergeben, die dann den Empfang der Daten veranlaßt (9). Eine Folge von 16 Verben "Receive Data" wird von Server 82 abgesetzt, da jedes Verb 512 Byte gleichzeitig anfordert und insgesamt 8 Kilobyte geschrieben werden.
Danach wird ein abschließendes Verb "Send Response" (10) von Server 82 vorbereitet, und eine Mitteilung, daß das Verb "Send Response" abgeschlossen wurde (11), wird an den Server 82 geliefert. Anschließend wird ein Hinweis von der IPCF an die Eingangswarteschlange von Requestor 80 gesendet (12). Requestor 80 setzt ein Verb "Receive Queue" ab (13) und empfängt den Antworthinweis (14).

DATENÜBERTRAGUNGSMODI UND GEMEINSAM GENUTZTER SPEICHER

Die IPCF bietet den Prozessen mehrere Optionen für die Handhabung und Verwaltung von Daten oder Anforderungen, die gesendet und empfangen werden. Diese Datenübertragungsmodi sind MOVE (Übertragen), PASS (Übergeben), LOCATE (Lokalisieren) und GETBUF/FREEBUF (Puffer anfordern/freigeben). Die genannten Datenübertragungsmodi beziehen sich sowohl auf Anforderungen als auch auf Daten. Ein Requestorprozeß wird als Sender bezeichnet, wenn er eine Arbeitsanforderung sendet, und als Empfänger, wenn er Daten empfängt. In ähnlicher Weise wird ein Server als Empfänger bezeichnet, wenn er eine Arbeitsanforderung empfängt, und als Sender, wenn er Daten an den Requestor liefert.
Eine Steuerfunktion für den Datenzugriff wird in der IPCF in jedem Prozessor definiert und sorgt dafür, daß die Positionen bei den definierten Datenübertragungsmodi transparent sind. Wenn Daten im Modus MOVE von einem Sender gesendet werden, erhält der Empfänger eine Kopie der Informationen. Jeder der kommunizierenden Prozesse hat stets seine eigene Kopie der Informationen zur Verfügung und weiß nicht, wie der andere Prozeß seine Kopie der Daten verwendet.
Im Modus PASS fertigt die Steuerfunktion für den Datenzugriff eine Zwischenkopie der Sendedaten in dem Speicher an, der für eine der an der Kommunikation beteiligten IPCFs zur Verfügung steht, so daß der Speicher des Senders sofort wieder benutzbar ist.
Im Modus LOCATE übergibt die Steuerfunktion für den Datenzugriff, wenn die kommunizierenden Prozesse Zugriff auf gemeinsam genutzten Speicher haben, einen Zeiger auf die Daten, und die Daten selbst werden nicht übertragen. Wenn die Prozesse keinen Zugriff auf gemeinsam genutzten Speicher haben, macht die Steuerfunktion für den Datenzugriff eine Kopie der im Speicher befindlichen Daten für den Empfänger der Daten verfügbar.
FREEBUF gestattet es einem Datensender, die Zuständigkeit für die Verwaltung der Puffer an einen Empfänger zu übergeben, der GETBUF angibt. Wenn der Sender und der Empfänger Zugriff auf gemeinsam genutzten Speicher haben, fällt das Übertragen von Daten weg. Wenn der Sender und der Empfänger keinen Zugriff auf gemeinsam genutzten Speicher haben, liefert die Steuerfunktion für den Datenzugriff eine Kopie der Puffer an den Empfänger.
Jeder der kommunizierenden Prozesse kann den von ihm gewünschten Datenübertragungsmodus unabhängig von dem vom anderen Prozeß verwendeten Modus verwenden. Die Steuerfunktion für den Datenzugriff kümmert sich um eventuell erforderliche zusätzliche Kopier- oder Übertragungsvorgänge der Daten, ohne daß besondere Maßnahmen von Seiten der kommunizierenden Prozesse erforderlich sind.
Wenn Daten im Modus MOVE gesendet werden, teilt der Sender der Steuerfunktion für den Datenzugriff mit, wo sich die Daten befinden, indem er einen "Ausgangsdaten-Deskriptor" (Data-Out Descriptor) DOD liefert, der die Sendedaten beschreibt. Dieser Deskriptor besteht aus einem oder mehreren Deskriptorelementen, die jeweils ein Längen- und Adressenpaar enthalten. Dem Empfänger wird nur eine Kopie der Daten verfügbar gemacht, selbst wenn der Empfänger den Modus LOCATE oder GETBUF verwendet. Der Speicher, der die Ausgangsdaten enthält, muß für die Dauer des Sendevorgangs verfügbar bleiben.
Wenn Daten im Modus MOVE empfangen werden, der von den Prozessen in Fig. 2 gewählt wurde, teilt der Empfänger oder Server 52 der Steuerfunktion für den Datenzugriff in der IPCF 57 mit, wo sie eine Kopie der empfangenen Daten speichern soll, indem er einen "Eingangsdaten-Deskriptor" (Data-In Descriptor) DID liefert, der die empfangenen Daten beschreibt. Dieser Deskriptor besteht aus einem oder mehreren lokalen Deskriptorelementen, die jeweils ein Längen- und Adressenpaar enthalten. Ein Deskriptorelement wird für jedes Speichersegment 60 geliefert, in dem die Daten oder die Arbeitsanforderung empfangen werden sollen. Die empfangenen Daten können auf jede vom Empfänger gewünschte Art segmentiert werden, und der Empfänger hat keine Kenntnis davon, auf welche Art die Daten vom Sender segmentiert wurden, da die Steuerfunktion für den Datenzugriff einen kontinuierlichen Datenstrom liefert.
Beim Modus MOVE muß der mit "AUSGANGSDATEN" im Requestorspeicher 58 bezeichnete Speicherbereich, der die Ausgangsdaten enthält, für die Dauer des Sendevorgangs verfügbar bleiben. Bei manchen Gelegenheiten möchte das sendende Programm oder Requestor 50 diesen Speicher sofort wieder nutzen, ohne warten zu müssen, bis das empfangende Programm 52 die Bearbeitung der Daten abschließt.
Wenn der Modus PASS angegeben wird, wie dies vom Requestor 50 in Fig. 5 getan wurde, bei der die Bezifferung mit der von Fig. 2 übereinstimmt, zeigt dies der Steuerfunktion für den Datenzugriff in der IPCF 55 an, daß sie sofort eine Kopie der Sendedaten anfertigen muß. Die Arbeitsanforderung wird in den Zwischenspeicher 62 kopiert, die Ausgangsdaten werden in den Zwischenspeicher 64 kopiert. Beim Empfang der Daten kann die Anfertigung einer zusätzlichen Kopie erforderlich sein, wenn die Daten im Modus MOVE empfangen werden oder wenn Server 52 sich in einem anderen Prozessor befindet als Requestor 50. Der gesamte durch die Deskriptoren der Ausgangsdaten beschriebene Speicher ist für die erneute Verwendung verfügbar, sobald die Ausgangsdaten kopiert wurden. Dies geschieht, bevor das empfangende Programm die Bearbeitung der Daten tatsächlich abschließt.
Das Senden der Daten im Modus LOCATE, wie in Fig. 6 dargestellt, verläuft ähnlich wie bei Verwendung des Modus MOVE. Ein Sender, Prozeß P1, teilt der Steuerfunktion für den Datenzugriff IPCF durch Lieferung eines DOD mit, an welcher Stelle sich die Daten im Speicher - Datenpuffer A im Speicherpool X - befinden. Die Festlegung des Modus LOCATE bedeutet, daß der Sender P1 zuläßt, daß der Empfänger P2 die Position des Datenpuffers A für die Sendedaten erhält. Wenn die Daten jedoch nicht im Modus LOCATE von P2 empfangen werden oder wenn kein gemeinsam genutzter Speicher vorhanden ist, wie es bei der Kommunikation zwischen P1 und P3 der Fall ist, muß die Steuerfunktion für den Datenzugriff auch in diesem Modus im Datenpuffer B des Speicherpools Y eine Kopie der Daten anfertigen.
Die Verwendung des Modus LOCATE bei einem Sendevorgang erfordert, daß der Speicher, der die Ausgangsdaten enthält, für die Dauer des zugehörigen Sendevorgangs verfügbar bleiben muß.
Der Datenempfang im Modus LOCATE unterscheidet sich in gewisser Weise vom Modus MOVE. Wenn Daten im Modus LOCATE empfangen werden, gibt nicht der Empfänger an, wo die Daten abgelegt werden sollen, sondern die Steuerfunktion für den Datenzugriff teilt dem Empfänger mit, wo sich die Daten befinden. Der Empfänger liefert beim Empfangsvorgang einen leeren Eingangsdaten-Deskriptor (DID). Die Elemente dieses Deskriptors werden von der Steuerfunktion für den Datenzugriff eingesetzt. Jedes Deskriptorelement enthält die Länge und Adresse eines Abschnitts der Daten. Die für den Empfänger sichtbare Segmentierung der Daten kann von der für den Sender sichtbaren Segmentierung abweichen. Wenn der Sender und der Empfänger über gemeinsam genutzten Speicher verfügen, ist es in den meisten Fällen nicht erforderlich, daß die Steuerfunktion für den Datenzugriff die Segmentierung der Daten verändert. Wenn die Daten jedoch übertragen werden müssen, werden sie so segmentiert, wie es für die Steuerfunktion für den Datenzugriff erforderlich ist.
Wenn die Daten im Modus MOVE oder PASS gesendet wurden oder der Sender und der Empfänger keinen Zugriff auf gemeinsam genutzten Speicher haben, muß eine Kopie der Daten angefertigt werden, wenn die Daten im Modus LOCATE empfangen werden. Die Steuerfunktion für den Datenzugriff beschafft Speicher für die Kopie. Dieser Speicher stammt aus dem für den Empfänger zugänglichen Speicher, beispielsweise Datenpuffer B für Prozeß P3 in Fig. 6. Die Steuerfunktion für den Datenzugriff gibt den gesamten beschafften Speicher nach Beendigung der Anforderung wieder frei.
Der Modus FREEBUF/GETBUF gestattet es dem sendenden und dem empfangenden Prozeß, die Zuständigkeit für die Verwaltung von Puffern, die Daten enthalten, vom sendenden an den empfangenden Prozeß zu übergeben. FREEBUF bezieht sich auf Sendedaten, GETBUF auf Empfangsdaten.
In den Modi MOVE, PASS und LOCATE ist der Sender für den Speicher zuständig, der die Sendedaten enthält u Zwischenkopien können angefertigt werden, und dem Empfänger kann der direkte Zugriff auf den Speicher gestattet werden; der Speicher, der das ursprüngliche Exemplar der Daten enthält, gehört aber noch immer zum Sender und untersteht seiner Zuständigkeit. Wenn der Modus FREEBUF verwendet wird, gibt der Sender die Zuständigkeit für den Speicher ab, der die Sendedaten enthält. Sobald Daten im Modus FREEBUF gesendet wurden, braucht sich der Sender um den Speicher, der sie enthält, nicht mehr zu kümmern. Die Steuerfunktion für den Datenzugriff stellt sicher, daß dieser Speicher später freigestellt wird oder daß die Zuständigkeit für ihn an den Empfänger übertragen wird. Der Sender darf keine Daten referenzieren, die im Modus FREEBUF gesendet wurden.
Puffer werden für die Steuerfunktion für den Datenzugriff wie bei anderen Datenübertragungsmodi mit Datendeskriptoren wie in Fig. 7 beschrieben. Jedes Puffer-Deskriptorelement enthält die Länge und die Adresse eines Puffers, dessen Kontrolle der Sender überträgt. Es muß jedoch nicht der gesamte Puffer in dem eigentlichen Sende- oder Empfangsdatenstrom enthalten sein. Der Sender kann einen Pufferabstand und eine Datenlänge im Puffer liefern, um anzugeben, welches Datensegment im Puffer in den Ausgangsbytestrom aufgenommen werden soll. Wenn die Daten empfangen werden, wird nur dieser Abschnitt für den Empfänger verfügbar gemacht. Dennoch wird der gesamte Puffer entweder von der Steuerfunktion für den Datenzugriff freigegeben oder an den Empfänger übergeben, wenn der Empfänger den Modus GETBUF verwendet und auf den Puffer zugreifen kann.
Die Möglichkeit der gemeinsamen Nutzung von Speicher wird durch Speicherpools festgelegt. Speicherpools sind lediglich benannte Speicherbereiche. Vor der Übertragung von Daten im Modus LOCATE oder GETBUF/FREEBUF liefern die kommunizierenden Prozesse der IPCF mit dem Verb "Specify Storage Pool" den Namen des Speicherpools, den sie jeweils verwenden. Wenn die kommunizierenden Prozesse für sich gegenseitig lokal sind und beide denselben Speicherpool verwenden, brauchen bei einer Übertragung zwischen ihnen keine Daten übertragen zu werden. Andernfalls geht die IPCF davon aus, daß kein gemeinsam genutzter Speicher verfügbar ist, und kopiert die Sendedaten. Wenn von einem der Prozesse der Modus MOVE oder PASS verwendet wird, werden die Daten in jedem Falle kopiert.
Jeder Benutzer liefert den Namen des Speicherpools, den er für seine Verbindungen jeweils verwenden möchte. Für eine oder mehrere Verbindungen kann derselbe Speicherpool verwendet werden. Wenn beide Benutzer einer Verbindung nicht denselben Namen liefern, kopiert die IPCF alle zwischen ihnen gesendeten Daten. Mit dem Verb "Specify Storage Pool" werden der IPCF Namen für Speicherpools angegeben. Es muß stets ein Standard-Speicherpool zur Verfügung stehen. Wenn kein Speicherpool explizit benannt ist, wird für Operationen im Modus LOCATE und GETBUF/FREEBUF ein Standard-Speicherpool verwendet.
Gesendete Daten können in den Modi MOVE, LOCATE oder GETBUF empfangen werden. In Tabelle 1 ist dargestellt, wie der Speicher für jeden der Empfangsmodi gehandhabt wird. Die Zahlen in Tabelle 1 entsprechen den Einzelschritten, die von der Steuerfunktion für den Datenzugriff (Data Access Control Function - DACF) durchgeführt werden und im folgenden beschrieben sind:
1. Der Empfänger stellt Speicher für Empfangsdaten zur Verfügung; die DACF führt eine Versetzung der Daten in den Empfängerspeicher durch.
2. Die DACF beschafft Speicher für eine Kopie der Daten.
3. Die DACF liefert dem Empfänger einen Zeiger auf eine Kopie der Daten (entweder im Speicher des Senders oder im von der DACF beschafften Speicher);
4. Der Sender verändert den ursprünglichen Speicher nicht, bevor der Sendevorgang abgeschlossen ist.
5. Der Sender kann den ursprünglichen Speicher sofort wieder verwenden, sobald die DACF den Übertragungsvorgang abgeschlossen hat.
6. Die DACF stellt den Speicher des Senders nach Abschluß der Anforderung frei.
7. Der Empfänger erhält die Kontrolle über den Puffer, der die Daten enthält (dies kann der ursprüngliche Puffer des Senders oder ein von der DACF beschaffter Puffer sein); die DACF stellt nicht empfangene Puffer frei.
8. Die DACF stellt Speicher, den sie beschafft hat (und der eine Kopie der Daten enthalten hat), nach Abschluß des Empfangsvorgangs frei. TABELLE 1 Vom Empfänger verwendeter Modus MOVE Vom Sender verwendeter Speichermodus LOCATE PASS FREEBUF (Gemeinsam genutzter Speicher verfügbar) nicht verfügbar GETBUF
Die IPCF stellt vorzugsweise keine Dienste für die Speicher- oder Pufferverwaltung zur Verfügung. Jede Implementierung der IPCF verwendet Speicherverwaltungseinrichtungen, die vom lokalen Betriebssystem des Prozessors, in dem sich die Prozesse befinden, zur Verfügung gestellt werden. Die IPCF verwendet diese Einrichtungen zur Zuweisung und Freistellung von Speicher, der für die Verwendung mit den Modi LOCATE und GETBUF/FREEBUF benötigt wird. Der Speicher für diese Modi stammt von den zugehörigen Speicherpools an jedem Prozessor.

REFERENZIERUNG VON DATEN

Während der Durchführung einer Anforderung kann ein Server-Prozeß Arbeitsanforderungen an andere Prozesse senden. Es ist nicht erforderlich, daß ein Zwischenprozeß Daten empfängt, die er nur an einen Sekundär-Server übergeben möchte. Die IPCF stellt ein Mittel zur Verfügung, mit dem die einer gegebenen Anforderung zugeordneten, als Bytestrom bezeichneten Daten die Daten aus den Byteströmen anderer Anforderungen aufnehmen können. Diese Fähigkeit wird als Referenzierung von Daten bezeichnet und ist durch das Verb "Send Request" abgedeckt.
Referenzierte Daten sind einer ausstehenden Anforderung zugeordnet, die an den diese Daten anfordernden Prozeß gesendet werden, und werden nicht wie bei Verwendung des Verbs "Receive Data" von dem Prozeß empfangen, der diese Daten mit einem Verb "Send Request" referenziert.
Ein Beispiel für die Datenreferenzierung ist in Fig. 8 dargestellt, in der die drei Prozesse P1, P2 und P3 kommunizieren. P1 setzt über eine IPCF-Verbindung 90 an P2 ein Verb "Send Request" ab (1), das Speicherstellen festlegt, von denen bei der Kommunikation Daten ausgehen sollen, und Speicherstellen, in die bei der Kommunikation Daten eingelesen werden sollen. Die Speicherstellen werden mittels Eingangsdaten-Deskriptoren (DID) und Ausgangsdaten-Deskriptoren (DOD) angegeben, die das Verb begleiten.
P2 wiederum setzt auf der IPCF-Verbindung 92 zwischen P2 und P3 ein Verb "Send Request" ab (2). P2 bearbeitet in diesem Beispiel nicht die von P1 bezeichneten Daten, sondern referenziert sie mit dem "Send Request" von P2 an P3. Da P2 die referenzierten Daten nicht bearbeitet, findet zwischen dem Speicher von P1 und dem Speicher von P2 keine Übertragung von Daten statt, und Datenpuffer in dem für P2 zugänglichen Speicher sind daher nicht erforderlich.
Der Transportmechanismus (38 und 40 in Fig. 1) übertragen anschließend die Daten (3) in die Speicher bzw. aus den Speichern in P3 und P1, ohne daß der Speicher von P2 beteiligt ist. P3 sendet anschließend eine Antwort mit Abschlußstatus (4) zurück an P2, und P2 sendet eine Antwort mit Abschlußstatus (5) zurück an P1. An dieser Stelle ist die Anforderung von P1 abgeschlossen.
Ein Aspekt der Referenzierung von Daten besteht darin, daß sich die Daten nicht in einem zusammenhängenden Speicherbereich befinden müssen. Die Daten müssen sich nicht einmal vollständig im Speicher eines der Prozessoren befinden. Dieser Aspekt der Referenzierung von Daten wird als "verteilter logischer Bytestrom" bezeichnet. Ein verteilter logischer Bytestrom ist logisch ein einzelner Datenbytestrom, der sich physisch in einem oder mehreren Prozessoren befindet, die über einen physischen Transportmechanismus verbunden sind, und muß nicht dem physischen Pfad der Arbeitsanforderung folgen, der er zugeordnet ist.
Bei verteilten logischen Byteströmen ist für einen Server, der eine Arbeitsanforderung verarbeitet, die physische Position der einzelnen Stücke, aus denen der Strom besteht, ohne Bedeutung. Der Server hat auch keine Kenntnis davon, daß die Arbeitsanforderung unter Umständen von einer Quelle in einem bestimmten Prozessor stammt, die zugehörigen Daten (der verteilte logische Bytestrom) aber von einer anderen Quelle in einem anderen Prozessor.
Ein verteilter logischer Bytestrom kann in einer Hierarchie von Servern übergeben werden, ohne zunächst empfangen zu werden. Arbeitsanforderungen, die sich auf einen verteilten logischen Bytestrom beziehen, werden zwischen den Servern übergeben, die sich in verschiedenen, durch einen Transportmechanismus verbundenen Prozessoren befinden und dort ausgeführt werden können. Die Daten, aus denen der verteilte logische Bytestrom besteht, müssen nicht gemeinsam mit den Arbeitsanforderungen physisch übertragen werden. Erst wenn der logische Bytestrom empfangen wird, wird er direkt in den Speicher in dem Prozessor übertragen, in dem er empfangen wird.
Ein neuer verteilter logischer Bytestrom kann gebildet werden, ohne andere Abschnitte des Bytestroms, die sich im Speicher anderer Prozessoren befinden, physisch zu übertragen (Fig. 10). Beispielsweise können Kopf und Schlußinformationen an den ursprünglichen Bytestrom angefügt werden, so daß ein neuer logischer Bytestrom gebildet wird. Kopf- und Schlußdaten befinden sich im Speicher eines Prozessors, der ursprüngliche Bytestrom im Speicher eines anderen Prozessors.
Ein verteilter logischer Bytestrom kann segmentiert werden, indem er in mehrere neue logische Byteströme aufgeteilt wird (Fig. 11), wobei jeder der neuen Byteströme einer gesonderten Arbeitsanforderung zugeordnet ist.
Die Datenstruktur, die einen verteilten logischen Bytestrom beschreibt, beinhaltet Deskriptorelemente in einer Arbeitsanforderung, wie zuvor in der Beschreibung von Fig. 2 dargestellt. Lokale Deskriptorelemente enthalten ein Adressen- und Längenpaar, das ein Stück des verteilten logischen Bytestroms beschreibt. Für jedes zusammenhängende Speicherstück, das einen Teil des im Speicher des Urhebers der Anforderung befindlichen Bytestroms enthält, wird ein lokales Deskriptorelement verwendet. In Fig. 9 sind bei 102 und 104 zwei lokale Deskriptorelemente dargestellt. Jeder Deskriptor stellt ein Datensegment durch eine Länge und eine Adresse dar. Die Datensegmente werden bei 106 und 109 in Übereinstimmung mit der Reihenfolge der Deskriptorelemente in der Arbeitsanforderung zusammengefügt und bilden den logischen Bytestrom 108.
Ein Referenz-Deskriptorelement enthält eine Anforderungskennung, die einen logischen Bytestrom kennzeichnet, die referenziert wird, indem ein logischer Zeiger auf den zu referenzierenden Abschnitt des verteilten logischen Bytestroms gesetzt wird. Der Zeiger verweist auf einen Satz von Deskriptorelementen in einem Puffer, die den referenzierten logischen Bytestrom beschreiben.
Das Referenz-Deskriptorelement enthält auch die Länge der gewünschten Daten in dem referenzierten logischen Bytestrom sowie einen Abstand zum Beginn der gewünschten Daten im referenzierten logischen Bytestrom. Die Anforderungskennung im Referenz-Deskriptorelement bietet Zugriff auf einen Satz referenzierter Deskriptorelemente, die von der IPCF verwaltet werden und den gesamten referenzierten logischen Bytestrom beschreiben.
In einer sortierten Liste lokaler Referenz-Deskriptorelemente wird der gesamte verteilte logische Bytestrom beschrieben und die Reihenfolge aller Stücke festgelegt, aus denen der verteilte logische Bytestrom besteht.
Fig. 10 zeigt einen möglichen Datenfluß, bei dem sich der logische Bytestrom in mehreren Prozessoren befindet. Ein erster Prozessor 110 enthält einen Requestor 112, der eine Arbeitsanforderung an einen Server-Prozeß 114 in einem zweiten Prozessor 116 sendet. Die Arbeitsanforderung ist durch eine Anforderungskennung "m" bezeichnet. Dieser Arbeitsanforderung sind Daten in der Form eines logischen Bytestroms zugeordnet, der mit 118 bezeichnet ist.
Ein DOD, der aus lokalen Deskriptorelementen besteht, die den verteilten logischen Bytestrom 118 beschreiben, begleitet die Arbeitsanforderung. Die Beschreibung enthält einen Satz von Adressen- und Längenpaaren, welche die Länge der Daten beschreiben, aus denen der logische Bytestrom in Prozessor 110 gebildet wird. Die Datenstrukturen, die über den Transportmechanismus von Prozessor 110 an Prozessor 116 gesendet werden, umfassen die Anforderungskennung "m", die Verbindungskennung sowie Deskriptorelemente, welche die Adresse des Prozessors 110 angeben, welcher die Daten 118 enthält, sowie die Speicheradressen und Längen der Daten 118 im Prozessor 110. Server 114 sendet eine Arbeitsanforderung an einen Server 120 in einem dritten Prozessor 122, wobei diese Arbeitsanforderung die Anforderungskennung "n" trägt. Dieser Arbeitsanforderung sind die mit 124 bzw. 126 bezeichneten Kopf- und Schlußdaten zugeordnet, deren Beschreibung gemeinsam mit einer Beschreibung des mit 118 bezeichneten Bytestroms in der Arbeitsanforderung "n" enthalten ist. Die Beschreibung der kombinierten logischen Bytestrom-Referenz, die der Arbeitsanforderung "n" zugeordnet ist, beinhaltet die Adresse des Prozessors 116 sowie die Speicheradresse und Länge der Kopfdaten 124 in Prozessor 116, die Adresse von Prozessor 110 und die Speicheradresse und Länge der Daten 118 in Prozessor 110 sowie die Adresse von Prozessor 116 und die Speicheradresse und Länge der Schlußdaten 126 in Prozessor 116.
Server 120 setzt als Teil seiner Bearbeitung von Arbeitsanforderung "n" ein "Receive" für den logischen Bytestrom ab. Dies führt zum direkten Übertragen des logischen Bytestroms aus den Speichern von Prozessor 110 und Prozessor 116 über einen Transportmechanismus 128 in Prozessor 122. Prozeß 120 legt fest, an welcher Stelle er die Daten mit Eingangsdaten-Deskriptorelementen wünscht. Prozeß 120 kennt nur seine Kopie des logischen Bytestroms und weiß nicht, daß sich die ursprünglichen Daten in mehreren Prozessoren befinden.
Die Steuerfunktion für den Datenzugriff ermöglicht auch die Segmentierung eines verteilten logischen Bytestroms in mehrere neue logische Byteströme. Jeder der neuen Byteströme kann getrennten Arbeitsanforderungen zugeordnet werden.
In Fig. 11 ist die Segmentierung eines verteilten logischen Bytestroms 150 gezeigt. Der Bytestrom 150 wird in einer Arbeitsanforderung von einem Requestor 152 an einen Server 154 referenziert. Server 154 bereitet seinerseits drei Arbeitsanforderungen vor, welche die Segmente SEG 1, SEG 2 und SEG 3 des Bytestroms 150 referenzieren. Diese Arbeitsanforderungen werden von einem Server 156 oder von anderen Servern empfangen, die anschließend die Daten empfangen oder weitere Anforderungen vorbereiten.

EINZELBESCHREIBUNG DES VERBENSATZES

OPEN (Öffnen)

Das Verb "Open" baut eine IPCF-Verbindung zwischen zwei Prozessen auf. Durch das Absetzen dieses Verbs wird die IPCF veranlaßt, eine logische Verbindung zwischen dem Prozeß, der das Verb "Open" abgesetzt hat, und dem Zielprozeß aufzubauen. Das Ziel des Verbs "Open" wird durch einen Identitätsnamen gekennzeichnet. Das Verb "Open" baut die Verbindung zu einem neuen oder bereits in Ausführung befindlichen Exemplar eines Programms in Abhängigkeit von dem durch das Verb "Open" gelieferten Entitätsnamen auf.
Das Verb "Open" beinhaltet einen Identitätsnamen, der von der IPCF und den zugehörigen Betriebssystemen verwendet wird, um das Programm und das Ausführungsexemplar (d. h. den Prozeß) dieses Programms zu ermitteln, zu dem die Verbindung hergestellt werden soll. Eine Verbindungskennung bezeichnet die Verbindung, die von der IPCF geliefert wird. Die Kennung wird verwendet, um bei nachfolgenden Operationen auf diese Verbindung Bezug nehmen zu kommen. Eine bestimmte Verbindungskennung ist nur innerhalb eines einzelnen Prozessors bekannt. Zwei verbundene Prozesse haben generell verschiedene Verbindungskennungen für dieselbe Verbindung. Verbindungskennungen werden von der lokalen IPCF zugewiesen und sind innerhalb eines Prozessors eindeutig.
Ein Rückkehrcode wird von der IPCF verwendet, um dem Prozeß den Abschluß des Verbs "Open" anzuzeigen.

CLOSE (Schließen)

Das Verb "Close" wird verwendet, um die logische Verbindung zwischen zwei Prozessen abzubrechen oder zu trennen. Das Verb kann von einem der beiden Prozesse oder von beiden Prozessen abgesetzt werden. Sobald das Verb "Close" abgesetzt wurde, wird der absetzende Prozeß daran gehindert, neue Arbeitsanforderungen auf der betreffenden Verbindung einzuleiten. Die Verbindung bleibt offen, bis alle ausstehenden Anforderungen abgeschlossen oder beendet wurden. "Close" darf nicht abgeschlossen werden, bevor der andere Prozeß eine sichere Benachrichtigung über das Verb "Close" erhält.
Es gibt zwei Arten des Verbs "Close": gesteuert und direkt. Das gesteuerte "Close" wird zum normalen Trennen verwendet. Es gestattet dem Prozeß, Anforderungen abzuschließen, die entweder bereits empfangen wurden oder sich in der Eingangswarteschlange des Prozesses befanden, als "Close" abgesetzt wurde. Das direkte "Close" wird für Fehler und abnormales Trennen verwendet.
Das Verb "Close" enthält eine Verbindungskennung, welche die zu trennende Verbindung bezeichnet. Der Typ des Verbs "Close" - gesteuert oder direkt - wird ebenfalls festgelegt, und es wird ein Rückkehrcode geliefert.

SPECIFY STORAGE POOL (Speicherpool festlegen)

"Specify Storage Pool" ermöglicht es, der IPCF einen Speicherpool anzugeben, der mit anderen IPCF-Benutzern potentiell gemeinsam genutzt werden kann. Für jede Verbindung, die ein Prozeß besitzt, kann nur ein Speicherpool festgelegt werden. Dieses Verb wird von einem Prozeß abgesetzt, wenn er keine ausstehenden Anforderungen besitzt.
Das Verb "Specify Storage Pool" enthält eine Verbindungskennung, die Einsprungadresse einer vom Benutzer gelieferten Speicherverwaltungsroutine, den Namen des für die Modi "Getbuf"/"Freebuf" zu verwendenden Speicherpools sowie einen Rückkehrcode.
Die Einsprungadresse einer vom Benutzer gelieferten Speicherverwaltungsroutine wird von der IPCF verwendet, um Speicher im festgelegten Speicherpool zuzuweisen und freizugeben. Wenn die Einsprungadresse nicht festgelegt ist, wird der vom System gelieferte Speicherverwalter verwendet.

SEND REQUEST (Anforderung senden)

"Send Request" sendet eine Anforderung an einen Server. Der Zielprozeß (der Server) ist durch die Angabe der zugehörigen Verbindungskennung festgelegt. Die Verbindungskennung wurde an den Quellprozeß geliefert, als die Verbindung mit dem Ziel aufgebaut wurde. Die Arbeitsanforderung für den Server wird mit einem Deskriptorparameter für die Anforderung festgelegt. Diese Anforderung enthält den Befehl für den Server und eventuell vorhandene zugehörige Parameter.
Ein Syntaxdiagramm für in einem Verb "Send Request" enthaltene Parameter ist in Fig. 22 dargestellt. Das Diagramm beginnt mit einem Sendeanforderungsparameter (send req), der angibt, daß es sich um ein Verb "Send Request" für die IPCF handelt. Die abzweigenden ausgezogenen Linien im Diagramm zeigen an, daß eine beliebige Linie mitsamt den zugehörigen, im Verb gelieferten Parametern verfolgt werden kann. Die folgende Liste enthält die Parameter mit den im Diagramm verwendeten Abkürzungen.

Cid Connection id (Verbindungskennung)

Rid Request id (Anforderungskennung). Alle Rids sind nur innerhalb eines einzelnen Prozessors eindeutig. Zwei verbundene Prozesse haben im allgemeinen verschiedene Rids für dieselbe Anforderung. Jeder dieser Prozesse kennt nur die Rid, die ihm von seiner lokalen IPCF zugeteilt wurde. Eine Rid ist ein Token, das von der lokalen IPCF verstanden wird und auf eine bestimmte Anforderung Bezug nimmt.
Reqpty Request Priority (Anforderungspriorität). Die Priorität einer Anforderung legt die Plazierung des zugehörigen Anforderungshinweises in der Eingangswarteschlange des Servers fest.
Rsppty Response Priority (Antwortpriorität). Wenn der Server diese Anforderung abschließt, kann er einen Status an den Requestor liefern. Der Requestor erhält diesen Status in einem Antworthinweis in seiner Eingangswarteschlange. Die Priorität der Antwort bestimmt die Anordnung dieses Antworthinweises in der Eingangswarteschlange des Requestors.
REQD Dies ist ein Anforderungsdeskriptor, der festlegt, welcher Datenübertragungsmodus für die Anforderung zu verwenden ist, und beschreibt, wie die Anforderung im Speicher des Requestors angeordnet ist. Da die Anforderung im Speicher nicht zusammenhängend sein muß, enthält dieser Deskriptor Sätze von Deskriptorelementen, und zwar jeweils ein Element für einen Abschnitt der Anforderung.
DOD Dies ist ein Ausgangsdaten-Deskriptor. Wenn Daten als Teil dieser Arbeitsanforderung gesendet werden sollen, wird ein Ausgangsdatendeskriptor geliefert. Der DOD legt fest, welcher Datenübertragungsmodus für die Ausgangsdaten verwendet werden soll. Er beschreibt auch, wie der logische Ausgangsbytestrom aufgebaut sein soll.
DID Dies ist ein Eingangsdaten-Deskriptor. Wenn Daten als Teil dieser Anforderung geliefert werden sollen, wird ein Eingangsdatendeskriptor geliefert. Gelieferte Daten können in den Requestorspeicher gestellt oder mit Hilfe von Referenz-Deskriptorelementen direkt an einen anderen Prozeß übergeben werden. Lokale Deskriptorelemente zeigen an, daß Daten an einen vom Requestor festgelegten Speicher geliefert werden sollen. Wenn für die gelieferten Daten GETBUF angegeben ist, beschreiben im Antworthinweis gelieferte Deskriptorelemente die gelieferten Daten. Es gibt in dieser Liste ein Deskriptorelement für jeden Speicherbereich, der die gelieferten Daten beinhaltet.
MOVE (Übertragen) Gibt an, daß Sende- oder Rückgabedaten im Modus "Move" übertragen werden sollen.
PASS (Übergeben) Gibt an, daß Sendedaten im Modus "Pass" übertragen werden sollen.
LOCATE (Lokalisieren) Gibt an, daß Sendedaten im Modus "Locate" übertragen werden sollen.
FREEBUF (Puffer freigeben) Gibt an, daß Sendedaten im Modus "FREEBUF" übertragen werden sollen. Der Requestor gibt die Zuständigkeit für den Speicher ab, der die im Modus "Freebuf" gesendeten Daten oder Anforderung enthält.
GETBUF (Puffer anfordern) Gibt an, daß gelieferte Daten im Modus "Getbuf" übertragen werden sollen. Der Requestor übernimmt die Zuständigkeit für die Verwaltung des Speichers, der die im Modus "Getbuf" gelieferten Daten enthält.
Maxin Legt die maximale Datenmenge in Byte fest, die vom Server für diese Anforderung geliefert werden kann. Der Server kann weniger als diese Menge liefern, erhält aber eine Fehlernachricht, wenn er versucht, mehr zu liefern. Die tatsächlich gelieferte Datenmenge kann durch Analyse der Puffer-Deskriptorelemente für die gelieferten Daten ermittelt werden.
Locde Dies ist ein lokales Deskriptorelement, das ein Segment eines logischen Bytestroms beschreibt. Bei einem REQD oder einem DOD legt dieser Deskriptor die Länge und Adresse eines durch den Requestor adressierbaren Speicherbereichs fest, der einen Abschnitt der gesamten Anforderung oder Ausgangsdaten enthält. Bei einem DID legt dieser Deskriptor die Länge und Adresse eines vom Requestor adressierbaren Speicherbereichs fest, in dem ein Abschnitt des gesamten Eingangsdatenstroms abgelegt werden soll.
Bufde Dies ist ein Puffer-Deskriptorelement, das einen einzelnen Puffer beschreibt. Ein Puffer ist eine Speichereinheit, für die Zuständigkeit übernommen (mit Getbuf) oder abgegeben (mit Freebuf) werden kann. Die Daten innerhalb des Puffers, die einen Abschnitt des Bytestroms bilden, müssen zusammenhängend sein, können aber kürzer als der gesamte Puffer sein. Puffer müssen von demjenigen Speicherpool aus zugewiesen werden, welcher der Verbindung zugeordnet ist, über die Daten in den Puffer gesendet oder daraus empfangen werden. Der Pufferdeskriptor beinhaltet eine Pufferadresse, Länge, den Abstand innerhalb des Puffers bis zum Beginn der eigentlichen Daten sowie eine Datenlänge.
Refde Dies ist ein Referenz-Deskriptorelement, das Daten innerhalb eines logischen Bytestroms referenziert, der einer anderen Anforderung zugeordnet ist. Wenn das Element innerhalb eines DOD verwendet wird, bilden die referenzierten Daten einen Eingangsdatenstrom zu dem Server-Prozeß, der das Ziel von SEND REQ ist. Bei Verwendung in einem DID ist der referenzierte Datenbereich ein Ausgangsdatenstrom in bezug auf den Server-Prozeß, der das Ziel von SEND REQ ist. Das Referenz-Deskriptorelement beinhaltet eine Referenzanforderungskennung, welche die Rid für die den referenzierten Daten zugeordnete Anforderung bildet. Das Element enthält außerdem einen Abstand innerhalb des der Referenz-Rid zugeordneten Bytestroms, der den Ursprung eines Abschnitts des referenzierten Bytestroms bezeichnet, der in den neu zu bildenden logischen Bytestrom aufgenommen werden soll; dieser Abstand gilt relativ zum Anfang des referenzierten Bytestroms. Das erste Byte des referenzierten Datenstroms hat den Abstand Null. Das Referenz-Deskriptorelement beinhaltet schließlich eine Datenlänge, die der Zahl der Bytes aus dem referenzierten Datenstrom entspricht, welche in das zu definierende Datenstromsegment aufgenommen werden sollen.
DEFRSP Gibt an, daß der Server den Status sowie optional den erweiterten Status in SEND RSP liefern muß. Der Status wird in den Antworthinweis in der Eingangswarteschlange des Requestors gestellt.
EXCRSP Zeigt an, daß der Server nur den Ausnahmestatus an den Requestor liefern soll. Der Server erhält die bestimmte oder Ausnahme-Antwortanzeige in dem Anforderungshinweis in der Eingangswarteschlange des Servers. Der Server verwendet diese Anzeige, um zu ermitteln, ob ein Status zu liefern ist. Wenn der Server im abschließenden SEND RSP keinen Status festlegt, wird in die Eingangswarteschlange des Requestors kein Antworthinweis gestellt. Wenn der Server in SEND RSP einen Status festlegt, wird ein Antworthinweis mit dem Status in die Eingangswarteschlange des Requestors gestellt.
Rc Von der IPCF gelieferter Rückkehrcode.

SEND RESPONSE (Antwort senden)

Das Verb "Send Response" wird vom Server verwendet, um Status und Daten an einen Requestor zu liefern. Da ein Server mehrere Anforderungen gleichzeitig verarbeiten kann, wird mit diesem Verb eine Anforderungskennung angegeben. Diese Kennung zeigt an, welcher Anforderung die gesendeten Informationen zugeordnet sind. Die Anforderungskennung für eine Anforderung ist im Anforderungshinweis enthalten, die der Server für jede Anforderung empfängt.
Der Server kann Abschnitte der Daten senden, sobald sie verfügbar werden. Aus der Sicht des Servers sendet er nur eine Folge von Bytes an den Requestor; jedes SEND RSP liefert den nächsten Teil der Folge. Der Server weiß nicht, an welcher Stelle im Speicher des Requestors die Daten abgelegt werden oder wie der Requestor seinen Datenpuffer segmentiert hat.
Eine Beschreibung der Parameter für "Send Response" ist in Fig. 13 in Form eines Syntaxdiagramms angegeben. Die drei Parameter, die nicht bereits oben in Zusammenhang mit dem oben beschriebenen Verb SEND REQUEST beschrieben wurden, werden im folgenden erläutert:
Offset Legt einen Abstand im Ausgangsdatenstrom fest, in dem die Sendedaten angeordnet werden sollen. Wenn kein Abstand angegeben wird, werden bei mehrmaliger Ausführung von SNDRSP (für dieselbe Rid) aufeinanderfolgende Abschnitte der Daten geliefert.
FINAL Zeigt an, daß dies die abschließende Antwort für die angegebene Anforderungskennung ist und daß die gesamte Verarbeitung der Anforderung abgeschlossen ist.
Status Zeigt als Status den endgültigen Abschluß für die gesamte Anforderung an.
Xstatus Liefert einen erweiterten Status für die Antwort vom Server an einen Requestor und ist optional.

RECEIVE QUEUE (Warteschlange empfangen)

Das Verb "Receive Queue" wird abgesetzt, um Hinweise zu beschaffen, die sich in der Eingangswarteschlange eines Prozesses befinden. Es gibt sechs Arten von Hinweisen:
1. Anforderung 2. Antwort 3. Signal 4. Öffnen 5. Schließen 6. Anforderung beenden
Wenn "Receive Queue" abgearbeitet ist, erhält der Prozeß normalerweise den ersten Hinweis in der Warteschlange. Der empfangende Prozeß kann zusammen mit "Receive Queue" einen Schlüssel liefern, der einschränkt, welchen Hinweis er in Zusammenhang mit der betreffenden Empfangswarteschlange akzeptiert. Das Syntax- Flußdiagramm in Fig. 14 enthält eine Beschreibung der Parameter für "Receive Queue". RCV Q zeigt an, daß es sich um denjenigen Empfangstyp handelt, bei dem der Empfang über eine Warteschlange erfolgt. Andere zuvor nicht beschriebene Parameter werden im Verlauf der folgenden Beschreibung erläutert:
Schlüssel Beschreibt einen Schlüssel, durch den eingeschränkt wird, welche Hinweise bei dem betreffenden "Receive Queue" akzeptiert werden. Der Schlüssel enthält Unterparameter, welche die Angabe zulassen, welche der sechs "Receive"-Hinweise die Eingangswarteschlange bilden dürfen. Wenn vom Schlüssel die Antwort (Response) als zulässig angegeben wird, kann auch die Anforderungskennung oder Verbindungskennung festgelegt werden.
Wird die Anforderung (Receive Request) angegeben, kann der Schlüssel eine Prioritätsstufe festlegen, von der an der Empfang aus der Warteschlange möglich ist. Sowohl bei Angabe der Anforderung (Request) als auch bei "Signal" kann eine Verbindungskennung angegeben werden. Auf diese Weise ist es möglich, einen ganz bestimmten Antworthinweis als zulässig festzulegen.
Timrval Dies ist der Zeitgeberwert in Millisekunden, während dessen der Absetzer von RCV Q auf die Antwort wartet.
Noteloc Dies ist diejenige Adresse im Speicher des Requestors, an die der Antworthinweis geliefert werden soll.
Notelen Legt die Größe eines Pufferbereichs im Speicher des Requestors fest, in den der Antworthinweis geliefert werden soll. Der Pufferbereich muß groß genug sein, um alle Hinweise aufzunehmen, die möglicherweise geliefert werden können.
WAIT Zeigt an, daß ein Prozeß ausgesetzt werden soll, wenn "Receive Queue" nicht erfüllt wird.
NOWAIT Zeigt an, daß ein Prozeß nicht ausgesetzt werden soll, wenn "Receive Queue" nicht erfüllt wird.
Anforderungshinweise (Request) werden in die Eingangswarteschlange eines Prozesses gestellt, wenn dieser das Ziel von "Send Request" eines anderes Prozesses ist. Anschließend wird "Receive Queue" ausgeführt, und der empfangende Prozeß erhält diesen Anforderungshinweis. Der Anforderungshinweis enthält die folgenden Informationen:
Verbindungskennung für die Verbindung zum Requestor
Anforderungskennung für die betreffende Anforderung
Anforderungslänge
Zahl der Anforderungssegmente
Länge der Eingangsdaten
Zahl der Eingangsdatensegmente
Priorität der Anforderung
Anzeiger: vom Requestor festgelegte bestimmte oder Ausnahmeantwort
Antworthinweise (Response) werden in die Eingangswarteschlange eines Prozesses gestellt, wenn ein anderer Prozeß "Send Response" ausführt und der Abschlußstatus anzeigt, daß eine Arbeitsanforderung abgeschlossen wurde. Der Antworthinweis enthält die folgenden Informationen:
Verbindungskennung für die Verbindung zum Server
Anforderungskennung für die Anforderung, die abgeschlossen wurde
Abschlußstatus
Puffer-Deskriptorelement, das den an den Requestor übergebenen Eingangsdatenpuffer beschreibt
Signalhinweise (Signal) werden in die Eingangswarteschlange eines Prozesses gestellt, wenn dieser das Ziel des Signals von einem andern Prozeß ist. Signalhinweise werden zum Senden kleiner Datenmengen zwischen zwei Prozessen verwendet. Der Signalhinweis enthält die folgenden Informationen:
Kennung der Verbindung, über die das Signal empfangen wurde Signaltyp (siehe Beschreibung des Verbs "Signal") Daten
Öffnungshinweise (Open) werden in die Eingangswarteschlange eines Prozesses gestellt, wenn auf Anforderung durch einen anderen Prozeß eine Verbindung zu ihm aufgebaut wurde. Der Öffnungshinweis enthält die folgenden Informationen:
Verbindungskennung
Statusfeld mit dem IPCF-Status
Schließhinweise (Close) werden in die Eingangswarteschlange eines Prozesses gestellt, wenn eine Verbindung mit ihm durch einen
anderen Prozeß abgebrochen wird oder wurde. Der Schließhinweis enthält die folgenden Informationen:
Verbindungskennung
Art des Schließens (ob das anstehende Schließen direkt oder gesteuert erfolgte)
und ob das Schließen abgeschlossen ist) Statusfeld
Hinweise auf das Beenden der Anforderung (Terminate Request) werden in die Eingangswarteschlange eines Server-Prozesses gestellt, wenn der Requestor eine anstehende Anforderung beendet. Der Hinweis enthält die folgenden Informationen:
Verbindungskennung, welche die Verbindung bezeichnet, deren Anforderungen beendet sind.
Anforderungskennung, welche die beendete Anforderung bezeichnet
Anzeiger: eine einzelne Anforderung oder alle Anforderungen in einer Verbindung sind beendet
Statusfeld.

RECEIVE REQUEST (Anforderung empfangen)

Das Verb "Receive Request" wird für den Empfang einer Arbeitsanforderung verwendet, die mit "Send Request" gesendet wurde. Diese Anforderung wird durch einen Anforderungsdeskriptor des Verbs Send Request gekennzeichnet. Der Empfänger muß eine Anforderungskennung und einen Anforderungsdeskriptor liefern. Die Anforderungskennung zeigt an, welche Arbeitsanforderung empfangen werden soll. Der Anforderungsdeskriptor beschreibt die Puffersegmente im Speicher des Servers, welche die empfangenen Daten enthalten sollen.
Das Syntaxdiagramm in Fig. 15 zeigt die Parameter des Verbs "Receive Request". Alle verwendeten Parameter wurden bereits weiter oben beschrieben. Das Verb "Receive Request" wird in den Modi "Move", "Locate" oder "Getbuf" verwendet. Im Modus "Move" legt der Empfänger eine lokale Speicheradresse fest, in der die empfangene Arbeitsanforderung abgelegt wird. In den Modi "Locate" und "Getbuf" liefert die IPCF an den Empfänger die Adresse der Arbeitsanforderung im lokalen Speicher. In beiden Fällen wird die tatsächliche Länge der Arbeitsanforderung in den Anforderungsdeskriptor aufgenommen.
Zur Unterstützung der Modi "Locate" und "Getbuf" enthält der vom Server empfangene Anforderungshinweis die Gesamtlänge und die Gesamtzahl der Speicherstücke, in welche die Arbeitsanforderung aufgeteilt ist. Dadurch kann ein Anforderungsdeskriptor so aufgebaut werden, daß, sofern gewünscht, der gesamte Anforderungsstrom mit einem einzelnen "Receive Request" empfangen werden kann.
Im Modus "Move" beschreibt der Anforderungsdeskriptor, an welcher Stelle die gelieferte Arbeitsanforderung abgelegt werden soll. Die Anforderung braucht nicht in zusammenhängendem Speicher abgelegt zu werden, sondern kann nach den Angaben des Empfängers in Abschnitte aufgeteilt werden. Für jeden Abschnitt der Anforderung wird ein lokales Deskriptorelement geliefert.
Die Verwendung des Modus "Locate" zeigt an, daß der Empfänger zwar Zugriff auf den Speicher wünscht, der die Arbeitsanforderung enthält, daß er aber keine eigene Kopie wünscht. Für den Empfang im Modus "Locate" werden eine maximale Empfangsdatenlänge sowie mehrere unbenutzte lokale Deskriptorelemente geliefert. Bei unbenutzten Deskriptorelementen ist nur das Typfeld ausgefüllt; Adressen- und Längenfeld sind nicht ausgefüllt. Beim Empfang der Arbeitsanforderung werden diese Deskriptorelemente von der IPCF ausgefüllt. Für jedes Segment der gelieferten Informationen wird ein Deskriptor verwendet.
Die Verwendung des Modus "Getbuf" zeigt an, daß der Empfänger Zuständigkeit für den Speicher wünscht, der die Arbeitsanforderung enthält. Für den Empfang im Modus "Getbuf" liefert man eine maximale Empfangsdatenlänge und mehrere unbenutzte Puffer-Deskriptorelemente. Bei unbenutzten Deskriptorelementen ist nur das Typfeld ausgefüllt; die restlichen Informationen werden beim Empfang der Arbeitsanforderung von der IPCF ausgefüllt. Für jedes Segment mit gelieferten Informationen wird ein Deskriptor verwendet.
Zum Verständnis der Funktionsweise des Abstandsparameters kann man sich vorstellen, daß die IPCF einen Zeiger auf den logischen Bytestrom richtet. Dieser Zeiger gibt die Position des nächsten vom Bytestrom zu empfangenden Bytes an. Wenn ein "Receive Request" ausgeführt wird, stammen die gelieferten Daten aus dem Anforderungs-Bytestrom ab dieser Position. Der Zeiger wird für jedes empfangene Byte um Eins erhöht. Wenn ein Abstand festgelegt ist, wird dieser Zeiger vor dem Datenempfang auf den Abstandswert gesetzt. Der Zeiger wird wie üblich inkrementiert, so daß Daten für nachfolgende "Receive Requests", bei denen kein Abstand festgelegt ist, aus dem Anforderungs-Bytestrom stammen, der mit dem Byte hinter dem letzten empfangenen Byte beginnt.

RECEIVE DATA (Daten empfangen)

"Receive Data" wird für den Empfang von Daten verwendet, die mit "Send Request" gesendet wurden. Diese Daten wurden durch den Ausgangsdatendeskriptor des "Send Request" bezeichnet. Der Empfänger muß eine Anforderungskennung und einen Eingangsdatendeskriptor bereitstellen. Die Anforderungskennung gibt an, welche Daten von welcher Anforderung empfangen werden sollen. Der Eingangsdatendeskriptor beschreibt, in welcher Form die Daten empfangen werden sollen.
Ein Syntaxdiagramm für Parameter, die das Verb "Receive Data" enthalten, ist in Fig. 16 dargestellt. Die Parameter wurden bereits weiter oben beschrieben.

SIGNAL (Signal)

Das Verb "Signal" gestattet es einem Prozeß, eine kleine Datenmenge an einen anderen Prozeß zu senden. Es veranlaßt, daß ein Signalhinweis in die Eingangswarteschlange des Zielprozesses gestellt wird. Da keine Antwort erwartet wird, ist einer Signal- Operation keine Rid zugeordnet.
Zu den Verwendungsmöglichkeiten von "Signal" gehören:
Lieferung des Zwischenstatus für eine Anforderung mit langer Ausführungsdauer.
Das Verb "Signal" beinhaltet vier Parameter: Cid, Signaltyp, Daten (wahlweise) sowie Rückkehrcode.

TERMINATE REQUEST (Anforderung beenden)

Das Verb "Terminate Request" wird verwendet, um anzuzeigen, daß die Verarbeitung von einer oder mehreren Anforderungen angehalten werden soll. Für die Beendigung einer einzelnen Anforderung wird eine Anforderungskennung geliefert.
Die Erfindung wurde hier in Form einer bevorzugten Ausführungsform beschrieben; für den Fachmann ist jedoch leicht ersichtlich, daß die Erfindung viele Einsatzmöglichkeiten besitzt. Sowohl für Einprozessorumgebungen als auch für Mehrpozessorumgebungen mit mehreren ausgeführten Prozessen ergeben sich durch diese Erfindung Vorteile durch die Verminderung des Speicherplatzbedarfs für die Prozesse und durch die Vereinfachung der Warteschlangenverwaltung. Die Transparenzeigenschaften dieser Erfindung ermöglichen aufgrund der verbesserten Mobilität der Prozesse eine wesentlich effizientere Zuweisung der Ressourcen.

Claims

1. Eine Prozeßkommunikationseinrichtung in einem verteilten Prozessorsystem, wobei jeder Prozessor über Speicherverwaltungsdienste verfügt, die Prozeßkommunikationseinrichtung (30, 32) den Datenaustausch zwischen mindestens zwei Prozessen (18, 19, 23, 24) leistet, die sich auf verschiedenen Prozessoren (12, 16) befinden können, die Einrichtung eine Mehrzahl verschiedener Datenübertragungsmodi unterstützt, deren Auswahl von den Prozessen gesteuert wird, und die Einrichtung bei jedem Prozessor besteht aus: einem mit jedem Prozeß (18, 19, 23, 24) gekoppelten Prozeßschnittstellenmittel, das eine gemeinsame Schnittstelle bietet, durch die jeder der kommunizierenden Prozesse Datenübertragungsmodi auswählt, wobei diese Auswahl von dem durch den anderen kommunizierenden Prozeß gewählten Datenübertragungsmodus unabhängig ist; weiterhin aus einem Steuermittel für den Datenzugriff, das mit dem Prozeßschnittstellenmittel und den Speicherverwaltungsdiensten gekoppelt ist, um die Speicherverwaltungsdienste als Funktion der von den kommunizierenden Prozessen gewählten Übertragungsmodi so steuern zu können, daß die Auswahl und die Verwendung der Übertragungsmodi für die kommunizierenden Prozesse transparent ist. Dies ist dadurch gekennzeichnet, daß das Steuermittel für den Datenzugriff mindestens einen ersten Datenübertragungsmodus unterstützen, in dem die zu übertragenden Daten zwischen dem sendenden und dem empfangenden Prozeß (50, 52) kopiert werden (62, 64), sowie einen zweiten Modus, in dem nur ein Zeiger auf die Daten übergeben wird; das Steuermittel für den Datenzugriff leistet darüber hinaus zumindest dann zusätzliche Verschiebe- oder Kopiervorgänge, wenn der zweite Modus vom sendenden Prozeß angegeben wurde und kein gemeinsamer Speicher zur Verfügung steht oder wenn vom sendenden Prozeß der eine der beiden Modi angegeben wurde und vom empfangenden Prozeß der andere; hierbei verwendet das Steuermittel für den Datenzugriff die Speicherverwaltungsdienste, die von den lokalen Betriebssystemen jedes der Prozessoren (12, 16) geleistet werden, und leistet keine eigenen Speicherverwaltungsdienste.

2. Die Prozeßkommunikationseinrichtung von Anspruch 1, dadurch gekennzeichnet, daß ein sendender Prozeß (50), der zu sendende Daten in einem ersten, ihm zugeordneten Speicherbereich (58) besitzt, mit einem empfangenden Prozeß (52) kommuniziert, der einen zweiten, ihm zugeordneten Speicherbereich (60) besitzt, wobei der sendende Prozeß (50) einen Übertragungsmodus unabhängig davon auswählt, ob er Zugriff auf den zweiten Speicherbereich (60) besitzt, und der empfangende Prozeß (52) einen Übertragungsmodus unabhängig davon auswählt, ob er Zugriff auf den ersten Speicherbereich (58) besitzt.

3. Die Prozeßkommunikationseinrichtung von Anspruch 2, dadurch gekennzeichnet, daß die Datenübertragungsmodi umfassen: Verschiebemodus zur Übertragung einer Kopie der Daten an die kommunizierenden Prozesse (50, 52); Übergabemodus zur Übertragung der Daten an den beim Datenaustausch empfangenden Prozeß (52); Lokalisierungsmodus zur Übertragung eines Zeigers auf die Daten, wenn sich diese im gemeinsamen Speicher befinden, bzw. Übertragung einer Kopie der Daten, wenn kein gemeinsamer Speicher verfügbar ist.

4. Die Prozeßkommunikationseinrichtung von Anspruch 3, dadurch gekennzeichnet, daß das Steuermittel für den Datenzugriff Datenverschiebevorgänge oder Datenkopiervorgänge leistet, die von der Auswahl der verschiedenen Übertragungsmodi durch jeden der Prozesse bewirkt werden, ohne daß eine Interaktion der kommunizierenden Prozesse (50, 52) erfolgt.

5. Die Prozeßkommunikationseinrichtung von Anspruch 3, dadurch gekennzeichnet, daß bei Festlegung des Verschiebemodus durch den sendenden Prozeß (50) eine Kopie der Daten für den empfangenden Prozeß (52) verfügbar gemacht wird, unabhängig von dem durch den empfangenden Prozeß (52) festgelegten Modus.

6. Die Prozeßkommunikationseinrichtung von Anspruch 3, dadurch gekennzeichnet, daß bei Festlegung des Übergabemodus durch den sendenden Prozeß (50) vom Steuermittel für den Datenzugriff eine Kopie der Daten erstellt wird und der erste Speicherbereich (58) anschließend wieder zur erneuten Verwendung verfügbar ist.

7. Die Prozeßkommunikationseinrichtung von Anspruch 3, dadurch gekennzeichnet, daß bei Festlegung des Lokalisierungsmodus durch den sendenden Prozeß (50) dem empfangenden Prozeß (52) der Direktzugriff auf die Daten gestattet wird, sofern sich diese in einem für den empfangenden Prozeß (52) zugänglichen Speicher befinden.

8. Die Prozeßkommunikationseinrichtung von Anspruch 7, dadurch gekennzeichnet, daß das Steuermittel für den Datenzugriff die Erstellung einer Kopie der Daten in dem Speicher (64) veranlaßt, der für den empfangenden Prozeß (52) verfügbar ist, wenn sich die zu sendenden Daten nicht in dem für den empfangenden Prozeß (52) zugänglichen Speicher (60) befinden.

9. Die Prozeßkommunikationseinrichtung von Anspruch 7, dadurch gekennzeichnet, daß das Steuermittel für den Datenzugriff die Erstellung einer Kopie der Daten in dem Speicher (64) veranlaßt, der für den empfangenden Prozeß (52) verfügbar ist, wenn der empfangende Prozeß (52) für den Empfang der Daten nicht den Lokalisierungsmodus angibt.

10. Die Prozeßkommunikationseinrichtung von jedem der Ansprüche 2 bis 9, dadurch gekennzeichnet, daß der sendende Prozeß (50) die Zuständigkeit für den ersten Speicherbereich (58) und der empfangende Prozeß die Zuständigkeit für den zweiten Speicherbereich (60) besitzt.

11. Die Prozeßkommunikationseinrichtung von jedem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß die Datenübertragungsmodi umfassen: Freebuf-Modus zur Abgabe der Zuständigkeit für einen Speicherbereich; Getbuf-Modus zur Annahme der Zuständigkeit für einen Speicherbereich.

12. Die Prozeßkommunikationseinrichtung von Anspruch 13, dadurch gekennzeichnet, daß durch die Festlegung des Freebuf- Modus durch einen sendenden Prozeß veranlaßt wird, daß das Steuermittel für den Datenzugriff eine Kopie der Daten im ersten Speicherbereich erstellt und die Steuerfunktion für den Datenzugriff die Zuständigkeit für den ersten Speicherbereich auf einen anderen Prozeß überträgt.

13. Die Prozeßkommunikationseinrichtung von Anspruch 12, dadurch gekennzeichnet, daß bei Festlegung von Getbuf durch den empfangenden Prozeß das Steuermittel für den Daten zugriff veranlaßt, dem empfangenden Prozeß die Zuständigkeit für einen Speicherbereich zu erteilen.

14. Die Prozeßkommunikationseinrichtung von Anspruch 12, dadurch gekennzeichnet, daß die Übertragung von Daten durch einen sendenden Prozeß, der Getbuf festgelegt hat, bewirkt, daß das Steuermittel für den Datenzugriff die Zuständigkeit für den ersten Speicherbereich (58) überträgt, der die Daten enthält, sofern der empfangende Prozeß (52) Zugriff auf den ersten Speicherbereich (58) hat.

15. Die Prozeßkommunikationseinrichtung von Anspruch 14, dadurch gekennzeichnet, daß das Steuermittel für den Datenzugriff dem empfangenden Prozeß (52) die Zuständigkeit für einen Speicherbereich (64) erteilt, der eine Kopie der Daten enthält, wenn die Daten sich nicht in gemeinsamen Speicher befinden.