DE3852324T2 - Verfahren und System zur Netzwerkverwaltung. - Google Patents
Verfahren und System zur Netzwerkverwaltung.Info
- Publication number
- DE3852324T2 DE3852324T2 DE3852324T DE3852324T DE3852324T2 DE 3852324 T2 DE3852324 T2 DE 3852324T2 DE 3852324 T DE3852324 T DE 3852324T DE 3852324 T DE3852324 T DE 3852324T DE 3852324 T2 DE3852324 T2 DE 3852324T2
- Authority
- DE
- Germany
- Prior art keywords
- node
- queue
- message
- network
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000007726 management method Methods 0.000 title 1
- 238000000034 method Methods 0.000 claims description 45
- 238000013507 mapping Methods 0.000 claims description 11
- 238000012546 transfer Methods 0.000 claims description 10
- 230000008569 process Effects 0.000 description 36
- 238000004891 communication Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- VJHCJDRQFCCTHL-UHFFFAOYSA-N acetic acid 2,3,4,5,6-pentahydroxyhexanal Chemical compound CC(O)=O.OCC(O)C(O)C(O)C(O)C=O VJHCJDRQFCCTHL-UHFFFAOYSA-N 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- IJJWOSAXNHWBPR-HUBLWGQQSA-N 5-[(3as,4s,6ar)-2-oxo-1,3,3a,4,6,6a-hexahydrothieno[3,4-d]imidazol-4-yl]-n-(6-hydrazinyl-6-oxohexyl)pentanamide Chemical compound N1C(=O)N[C@@H]2[C@H](CCCCC(=O)NCCCCCC(=O)NN)SC[C@@H]21 IJJWOSAXNHWBPR-HUBLWGQQSA-N 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Multi Processors (AREA)
Description
- Diese Erfindung befaßt sich mit dem Informationsaustausch zwischen Vorgängen, die an unterschiedlichen Knoten in einem Datenverarbeitungsnetzwerk angeordnet sind. Jeder Knoten umfaßt einen Prozessor, der zum selbständigen Betrieb in der Lage ist, und kann andere Dienste umfassen, wie etwa Datenstationen, Speicher- und E/A-Geräte. Weiterhin kann jeder Prozessor zur Simultanverarbeitung und zum Multitaskingbetrieb fähig sein. Insbesondere befaßt sich die vorliegende Erfindung mit der Unterstützung eines warteschlangenbasierten Informationsaustausches zwischen Vorgängen, die am selben oder an einem unterschiedlichen Knoten im Netzwerk angeordnet sind, indem es für ein Programm nichtmehr notwendig ist, daß es den Knoten der Warteschiangen des Informationsaustausches kennt. Die Transparenz des Warteschlangenstandortes bei der Prozeßkommunikation (IPC) wird beschrieben, wie sie in einer Umgebung mit verteilten Diensten realisiert ist.
- In The Design of the UNIX¹ Operating System von M. J. Bach (Prentice-Hall 1986) wird auf den Seiten 356 bis 367 beschrieben, daß die Prozeßkommunikation (IPC) erfolgen kann, indem der Systemaufruf zum Nachrichteneinholen (MSGGET) mit eineiu Schlüssel aufgerufen wird, der im systemresidenten Kern eine Durchsuchung eines Bereiches von Nachrichtenwarteschlangen aufruft und, falls er für den angegebenen Schlüssel keinen passenden Eintrag findet, eine neue Warteschlangenstruktur zuordnet und an den Benutzer eine Kennzeichnung zurückschickt. Die mit den Systemaufrufen MSGSND und MSGRCV verbundenen Algorithmen für das Absenden beziehungsweise Empfangen von Nachrichten werden beschrieben. Es gibt jedoch keine Beschreibung oder Vorschläge hinsichtlich der Unterstützung der Prozeßkommunikation zwischen Vorgängen, die an ¹ Warenzeichen von AT&T Bell Laboratoriesunterschiedlichen Knoten eines Netzes angeordnet sind.
- Der RT²-Personalcomputer von IBM wird in dem Buch IBM RT Personal Cornputer Technology (Form Nr. SA23 - 1057) beschrieben. Darin wird die Betriebssystemstruktur Advanced Interactive Executive (AIX³) als eine Erweiterung der Konzepte des UNIX-Systems C von AT&T beschrieben.
- Der AIX-Kern realisiert die Arbeitsumgebung für Anwendungsprogramme und Steuerbefehle. Eine ausführlichere Beschreibung von AIX befindet sich in AIX Operating System Technical Reference (Form Nr. SV21 - 8009). Diese Technologie ist nunmehr erweitert worden, damit eine Vielzahl von RT-PC-Systemen von IBM Knoten in eineni Datenübertragungsnetzwerk sein können und damit zusätzliche Merkmale bereitgestellt werden können.
- Ein solches Merkmal besteht in der verteilten Verarbeitung innerhalb des Netzwerkes. Eine solche Umgebung mit verteilten Diensten umfaßt zwei oder mehr Knoten, die durch eine Datenübertragungsstrecke oder ein Datenübertragungsnetzwerk miteinander verbunden sind. Ein derartiges Netzwerk kann entweder ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) sein, das Datenfernverarbeitungsverbindungen zu anderen Knoten oder zu anderen Netzwerken umfaßt. Ein primäres Ziel der verteilten Dienste besteht darin, lokale/Fern-Transparenz für Anwendungen bereitzustellen, die das Dateisystem und die Dienste der Prozeßkommunikation des AIX-Betriebssystems benutzen.
- "Distributed System V IPC in LOCUS: A Design and Implementation Retrospective" von B. D. Fleisch in Computer Communication Review, 5. bis 7. August 1986, Nr. 3, Stowe, Vermont, USA, beschreibt ein Netzwerkverwaltungssystem zur Prozeßkommunikation zwischen Benutzeranwendungsprogrammen in einem Netzwerk mit verteilten Diensten, das Prozessoren umfaßt, von denen sich jeder ² RT und RT PC sind Warenzeichen der IBM Corporation³ AIX ist ein Warenzeichen der IBM Corporationan einem unterschiedlichen Knoten befindet. Jeder Prozessor umfaßt speicherresidente Systembetriebsmittel und Programme zum Anlegen von und zum Zugriff auf Nachrichtenwarteschlangen. Jeder Prozessor ist in der Lage, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen. Der Informationsaustausch zwischen den Prozessoren erfolgt über Warteschlangen, die an jedem beliebigen Knoten im Netzwerk angeordnet sind. Für alle Untersysteme der Interprozeßkommunikation innerhalb des Netzwerkes wird eine einzige Namendatenbank aufrechterhalten.
- EP-A-201 063 beschreibt ein weiteres Netzwerkverwaltungssystem für Prozeßkommunikation zwischen Benutzeranwendungsprogrammen in einem Token-Ring-Netzwerk mit verteilten Diensten, das eine Vielzahl von Zellen umfaßt. Jede Zelle umfaßt speicherresidente Systembetriebsmittel und Programme zum Anlegen von und Zugreifen auf Nachrichtenwarteschlangen. Jede Zelle ist in der Lage, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen. Der Informationsaustausch zwischen Zellen erfolgt über Warteschlangen. Ein nicht residenter Cache-Speicher für Prozeßnamen in jeder Zelle bezeichnet die nächste Zelle im Token-Ring, bei der ein genannter Prozeß zu finden ist.
- Gemäß der vorliegenden Erfindung wird hier ein Verfahren zur Verfügung gestellt, mit dem der Informationsaustausch zwischen Denutzeranwendungen unterstützt wird, die an Prozessoren ausgeführt werden, die an einem oder mehreren Knoten in einem Netzwerk angeordnet sind, wobei Nachrichtenwarteschlangen benutzt werden, deren aktuelle Knotenstandorte für die Benutzerprogramme transparent sind, wobei das Verfahren die Schritte umfaßt: an jedem Knoten eine Schlüsselabbildungstabelle im Speicher aufrechtzuerhalten, das die den Anwendungen, die an jedem Knoten laufen, zugeordneten knotenelndeutigen Warteschlangenschlüssel mit dem aktuellen Knotenstandort der Warteschlange und den Schlüsseln der Nachrichtenwarteschlangen verbindet; mit einem von einer Anwendung bereitgestellten Schlüssel auf eine Schlüsselabbildungstabelle zugreifen, um den Knoten und den Schlüssel einer Nachrichtenwarteschlange zu erhalten und eine Datenübertragung zwischen dem Anwendungsknoten und dem Knoten der Nachrichtenwarteschlange aufzubauen.
- Wenn man die vorliegende Erfindung unter einem anderen Aspekt betrachtet, so wird nun ein Netzwerkverwaltungssystem zur Verfügung gestellt, mit dem man den Benutzeranwendungsprogrammen in einem Netzwerk mit verteilten Diensten die Knotenstandorte einer Nachrichtenwarteschlange transparent machen kann, wobei das Netzwerk Prozessoren umfaßt, von denen sich jeder an einem verschiedenen Knoten befindet, wobei jeder Prozessor speicherresidente Systembetriebsmittel und Programme zum Anlegen von und zum Zugreifen auf Nachrichtenwarteschlangen umfaßt und jeder Prozessor in der Lage ist, eine Vielzahl von Benutzeranwendungsprogrammen auszuführen, wobei der Informationsaustausch zwischen den Prozessoren über Warteschlangen erfolgt, die an einem beliebigen Knoten innerhalb des Netzwerkes angeordnet sind, wobei das System dadurch gekennzeichnet ist, daß es umfaßt: von jedem Knoten aufrufbare Bibliotheksprogrammittel zur Zuordnung von knoteneindeutigen Schlüsseln zu jedem von einem Benutzeranwendungsprogramm bereitgestellten Warteschlangennamen; Tabellenlademittel, die beim Prozessoranlauf betriebsfähig sind, damit sie an jedem Knoten eine kernresidente Abbildungstabelle mit Einträgen bereitsteilen, welche die zugeordneten knoteneindeutigen Schlüssel mit den Knoten und Schlüsseln der Standorte der Nachrichtenwarteschlangen verbinden; und Mittel zum Empfang eines vom Benutzeranwendungsprogramm bereitgestellten Schlüssels, der den zugehörigen Standortknoten einer Nachrichtenwarteschlange fixiert und eine Datenübertragung zwischen dem Knoten des Benutzeranwendungsprogramms und einem Standortknoten einer zugehörigen Nachrichtenwarteschlange aufbaut, damit ein Nachrichtenübermittlungsvorgang erfolgen kann.
- Die gegenwärtige Erfindung unterstützt den Informationsaustausch zwischen Prozessen, die sich an verschiedenen Knoten in einem Netzwerk befinden können, das mindestens zwei über eine Datenübertragung miteinander verbundene Systeme umfaßt. Jeder Knoten umfaßt einen Prozessor, der zur Simultanverarbeitung und zum Multitasking in der Lage ist. Wie nachstehend beschrieben, kann jeder Knotenprozessor ebenso selbständig betrieben werden.
- An unterschiedlichen Knoten angeordnete Prozesse werden in die Lage versetzt, unter Verwendung von IPC-Warteschlangen miteinander zu kommunizieren, wobei deren tatsächliche Knotenstandorte dem Programm unbekannt sind, das den Informationsaustausch auslöst. Die vorliegende Erfindung ist gegenüber der Fähigkeit der AIX-IPC-Nachrichtenwarteschlange zum Informationsaustausch zwischen Prozessen im gleichen AIX-System ein Fortschritt, indem die Nachrichteneinrichtungen von AIX IPC dahingehend erweitert werden, daß sie zum Absenden und Empfangen von Nachrichten zwischen Warteschlangen an unterschiedlichen Knoten in der Lage sind. AIX unterstützt IPC, indem es die Systemaufrufe zur Nachrichteneinholung (msgget), zur Nachrichtenabsendung (msgsnd) und zum Nachrichtenempfang (msgrcv) benutzt. Die Nachrichteneinholung wird dafür benutzt, daß eine Nachrichtenwarteschlange zu finden oder anzulegen und ihre Kennzeichnung MSQID zurückzuschicken ist. Nachfolgende Aufrufe zum Absenden oder Empfangen von Nachrichten benutzen diese MSQID zum Kennzeichnen der Zielwarteschlange.
- Die vorliegende Erfindung geht über eine Modifizierung am früheren Systemaufruf AIX msgget hinaus, indem weiterhin enthalten ist, daß sie einen Schlüssel einer spezifischen Warteschlange als Argument benutzt, um eine Funktion in einer vorherdefinierten kernresidenten Tabelle zu finden, die den Eingabeschlüssel mit dem aktuellen Schlüssel und dem Knotenstandort dieser spezifischen Warteschlange verbindet. Der Knotenstandort und der Schlüssel der Warteschlange, in der eine Nachricht eingereiht werden soll, sind für die Nachrichtenaustauschvorgänge transparent.
- Wenn sich die Warteschlange in einem entfernten Knoten befindet, dann benutzen die beiden Knoten eine zwischen ihnen eingerichteten Datenübermittlungsabschnitt, um die Information der Warteschlangenelemente zu übergeben. Beschreibungsgemäß benutzt die bevorzugte Ausführungsform der Erfindung die Systems Network Architecture (SNA) 6.2 Advanced Program to Program Communication von IBM.
- Die IPC-Nachrichtenwarteschlangen werden mit einem Schlüssel gekennzeichnet, einem Zahlenwert, der beim Anlegen der Warteschlange zugeordnet wird. Jeglicher Vorgang, der Zugriff zu einer spezifischen Warteschlange haben möchte, muß auf solche Art darauf Bezug nehmen, daß die Bezugnahme beim aktuellen Warteschlangenkennzeichen aufgelöst werden kann.
- Wie nachstehend beschrieben, wird die bevorzugte Ausführungsform der vorliegenden erfindungsgemäßen Verfahrensweise bei der Betriebssystemebene realisiert, wo Einrichtungen für verteilte Dienste zur Verfügung gestellt werden. Die vorliegende Erfindung erfordert es, daß jeder Systemknoten in einem Netzwerk seinen eigenen Profilnamenbereich der IPC-Warteschlangen für Schlüssel hat. Vom Aufruf eines Anwendungsprogramms wird ein knoteneindeutiger Schlüssel an ein Bibliotheksprograrnm zurückgegeben, das einen knoteneindeutigen Schlüssel mit einem vom Aufrufer gegebenen Warteschlangennamen verbindet.
- Die vorliegende Erfindung erfordert auch Schlüsselabbildungstahellen (KMT), die im Kern jedes Systems resident sind. Jeder Eintrag in eine Schlüsselabbildungstabelle umfaßt den örtlichen Schlüssel, der sich auf eine spezifische Warteschlange bezieht, den Knoten, in dem sich die Warteschlange augenblicklich befindet, und den an dem Knoten verwendeten Schlüssel, wo sich die Warteschlange augenblicklich befindet. Die KMTs werden zum Zeitpunkt des Systemanlaufs in den Kern jedes Knotens geladen.
- Die KMT-Daten werden von einem Netzwerkverwalter aufrechterhalten, der das Netzwerk beaufsichtigt. Vom Netzwerkverwalter werden je nach Bedarf Veränderungen an den KMTs durchgeführt. Diese administrative Einbeziehung des Bedieners ermöglicht eine Transparenz der Nachrichtenwarteschlangen an der Anwendungsschnittstelle.
- Wie in dem Buch von Bach beschrieben, kommunizierten die Prozesse früher dadurch, daß unter Verwendung von Nachrichtenwarteschlangen Nachrichten abgesandt und empfangen wurden. Der aufrufende Prozeß muß die Warteschlange identifizieren, in welcher der empfangende Prozeß erwartet, Nachrichten zu finden. Bei dezentralen Simultanverarbeitungssystemen sind alle Warteschlangenstandorte bekannt. In einer Netzwerkumgebung mit verteilten Diensten ist es für die Vorgänge jedoch wünschenswert, über Nachrichtenwarteschlangen, die sich am gleichen oder an einem verschiedenen Knoten befinden können, mit Vorgängen zu kommunizieren, die sich an anderen Knoten befinden können. Es wäre unannehmbar, von jedem Vorgang zu fordern, daß er für alle Nachrichtenwarteschlangen im Netzwerk implizit die Standortinformation kennt. Wenn dies gefordert würde, dann wären bei jedem Aufrufvorgang immer dann Veränderungen notwendig, wenn sich der aktuelle Standort der Nachrichtenwarteschlange geändert hat.
- Die vorliegende Erfindung löst dieses Problem, indem sie kernresidente Tabellen einführt, die Warteschlangenschlüssel an diesem Prozessorknoten mit dem aktuellen Schlüssel und dem Knotenstandort der Nachrichtenwarteschlange verbinden. Diese Tabellen können von einem Netzwerkverwalter geändert werden, um die Veränderungen am aktuellen Knotenstandort der Nachrichtenwarteschlange widerzuspiegeln. Die vom aufrufenden Vorgang bereitgestellten Eingabeparameter ändern sich nicht. Deshalb sind an der Schnittstelle des Anwendungsprogramms die aktuellen Knotenstandorte von Nachrichtenwarteschlangen transparent.
- Auf der Kernebene erfolgt die Adressenauflösung zum aktuellen Kennzeichen der Nachrichtenwarteschlange. Die KMTs empfangen als Eingabe einen Schlüssel und stellen für die gewünschte Warteschlange eine Schlüssel- und Knoten-id zur Verfügung. Die Systemaufrufroutinen innerhalb eines Kerns jedes derart verbundenen Knotens nehmen den Schlüssel, der von dem den Informations- austausch auslösenden Vorgang bereitgestellt wird, und gehen zu dem entsprechenden Schlüssel und Knoten. Wenn in der Kennsatztabelle der Warteschlangen dieses Knotens eine Nachrichtenwarteschlange mit dieser Kennzeichnung nicht auffindbar ist, dann wird eine neue angelegt, wenn der Aufrufer das Anlegen einer Warteschlange fordert, und die Kennzeichnung dieser Nachrichtenwarteschlange wird an den Kern des aufrufenden Knotens zurückgeschickt. Im Kern des aufrufenden Knotens wird eine neue Aliaseintragung des Warteschlangenkennsatzes aufgebaut, die den aktuellen Knotenstandort und das Kennzeichen der Nachrichtenwarteschlange umfaßt. Die Anwendung ist dann in der Lage, ihre Nachricht in der beabsichtigten Nachrichtenwarteschlange unterzubringen.
- Es ist eine Aufgabe der gegenwärtigen Erfindung, für Nachrichtenwarteschlangen ein wirkungsvolles Handhabungssystem mit Transparenz des Knotenstandortes, Mittel zur Vermeidung des Zuordnens von sich widersprechenden Warteschlangennamen und Mittel zur Entschachtelung von Nachrichten in einer Warteschlange von einem gegebenen Dienstprogramm aus einer Vielzahl von Mandanten zur Verfügung zu stellen.
- Diese und andere Merkmale und Vorteile der Erfindung, die in den beigefügten Ansprüchen definiert ist, werden aus der folgenden Beschreibung im Zusammenhang mit den zugehörigen Zeichnungen besser augenscheinlich, wobei:
- Figur 1 eine schematische Darstellung eines Netzwerkes mit einer Vielzahl von Knoten ist, in dem die vorliegende Erfindung realisiert sein kann.
- Figur 2 zeigt das Ebrmat eines Eintrags in einer Schlüsselabbildungstabelle.
- Figur 3 zeigt den Inhalt eines Eintrags in einer Warteschlangenkennsatztabelle.
- Figur 4 zeigt das Format eines Nachrichtenwarteschlangeneintrags.
- Figuren 5A, 5B und 5C zeigen den logischen Ablauf während der Prozeßkommunikation.
- Figur 6 zeigt das Beispiel einer Prozeßkommunikation mit hypothetischen Werten.
- Unter Bezugnahme auf Figur 1 wird nun ein Netzwerk erläutert, in dem die vorliegende Erfindung ausgeführt wurde. Es ist ein Netzwerk 10 dargestellt, das eine Vielzahl von Knoten A, B und C umfaßt, die über einen Datenübermittlungsabschnitt 30 verbunden sind. Jeder Knoten A, E, C umfaßt mindestens einen Prozessor 40, der multitasking- und simultanverarbeitungsfähig ist, dem als dezentrales System oder als Teil des Netzwerkes 10 arbeiten kann.
- Es wird ein Nachrichtennetzwerk 30 dargestellt, das aus einem lokal es Netzwerk oder aus einem Weitverkehrsnetz bestehen kann, aber die bevorzugte Ausführungsform realisiert die IBM Systems Network Architecture zum Aufbau von Datenübertragungen zwischen den Knoten A, B und C. Jeder Knoten umfaßt mindestens einen Prozessor 40, für den Benutzeranwendungen 42 geschrieben wurden. Im Inneren des Prozessors 40 werden die Prozesse 44 durch ein Betriebssystem 46 gesteuert, das in der bevorzugten Ausführungsform das AIX von IBM ist. Die Beschreibungen der verschiedenen ebenfalls anhängigen gemeinsam übertragenen Anmeldungen, die durch Bezugnahme hierin enthalten sind, umfassen die Beschreibungen der verschiedenen Aspekte des Systems, in dem die vorliegende Erfindung ausgeführt ist. Die gegenwärtige Beschreibung ist auf diejenigen Aspekte der Netzwerkkonfiguration 10 beschränkt, die eine spezifische Bedeutung für die Erfindung haben.
- Mit jedem Prozessor 40 sind verschiedene Arten von Speichermedien verbunden, wie sie bei 48 dargestellt sind. Die verschiedenen Datenend- Speicher- und peripheren E/A-Geräte, die mit jeden Prozessorknoten in einem Netzwerk verbunden sein können, werden nicht dargestellt, sind jedoch in der Netzwerkkonfiguration 10 mit inbegriffen. Im Inneren des Betriebssystems 46 befindet sich bei jedem Prozessor 40 ein Kern 50.
- Die Beschreibung anderer Aspekte der Erfindung bezieht sich ebenfalls auf die Figur 1.
- Jeder autonome Knoten A, B, C kann mit einem anderen zusammenarbeiten, um die an einem anderen Knoten verfügbaren Betriebsmittel für die Durchführung einer gegebenen Aufgabe gemeinsam zu benutzen. Bei einer solchen Umgebung mit verteilten Diensten ist ein minimaler Benutzerdialog erforderlich, um die Möglichkeiten vorteilhaft zu nutzen, die von der gegenwärtigen Erfindung zur effizienten Nachrichtenhandhabung durch die Transparenz der Standorte der Nachrichtenwarteschlangen geboten werden. Die gemeinsame Benutzung von Betriebsmitteln vermindert die Notwendigkeit, Information an jedem Knoten im Netzwerk zu wiederholen.
- Der Informationsaustausch zwischen Prozessen ist effizienter, und für die Einzelheiten des Informationsaustausches sind weniger Benutzeraufrufe erforderlich, da der Knotenstandort der Warteschlangen des Nachrichtenaustausches für das Benutzerprogramm transparent ist. Obwohl sich der aktuelle Knotenstandort einer gegebenen Warteschlange verändern kann, wird der Benutzer eines gegebenen Knotens von der Verantwortung befreit, den Standort der Warteschlangen zu verfolgen. Eine Funktion des Netzwerkverwalters besteht darin, einen aktuellen Satz von Profilen aufrechtzuerhalten, welche die Warteschlangenschlüssel und den Standort miteinander verbinden, und die entsprechende Verbindungsinformation in die KNT in den Kern 50 jedes Knotens im Netzwerk zu laden.
- Im Betriebssystem 46 für jeden Prozessorknoten in der Netzwerkkonfiguration 10 sind Verzeichnisdienstfunktionen inbegriffen, die für die vorherdefinierten Warteschlangen erforderliche Information aufrechterhalten. Diese Funktionen umfassen das Anlegen eines IPC-Schlüssels, die Definition seines Standortes und die Auflösung der externen IPC-Warteschlangennamen in einen Schlüssel für eine spezifische Nachrichtenwarteschlange und die Rücksendung des Netzwerkstandortes und der entfernten Warteschlange von dem Knoten, von dem die Nachricht kommen wird.
- Ein Verzeichnis der Warteschlangenprofile, dessen Format bei 52 in Fig. 1 erläutert ist, wird als Ergebnis der Ausführung einer Bibliotheksroutine zur Anlage von IPC-PROF angelegt, die vom Installationsprogramm einer Anwendung aufgerufen wurde. Das Programm liefert einen Warteschlangennamen, der bis zu 14 Zeichen lang sein kann, und die Bibliotheksroutine legt das Profilverzeichnis an und ordnet einen numerischen INKEY-Wert zu, der für diesen Knoten eindeutig ist. Zum Zeitpunkt des Systemanlaufs liest das System die Profile und legt die KNT mit den Einträgen an, wie es in Figur 2 dargestellt ist, wobei der örtliche Schlüssel LKEY, der von der Bibliotheksroutine zugeordnet wird, und der aktuelle Schlüssel RKEY und der aktuelle Knoten RNODE für die vom LKEY bezeichnete Warteschlange enthalten sind.
- Figur 3 zeigt das Format eines Verzeichnisses der Warteschlangenkennsätze. Ein Prozeß im Dienstprogramm gibt zum Zeitpunkt des Anlaufs einen Warteschlangennamen an find_IPC_PROF ein und empfängt den mit dieser Warteschlange verbundenen Schlüssel. Der Prozeß des Dienstprogramms gibt dann einen Systemaufruf heraus, msgget, indem er einen Schlüssel zur Verfügung stellt, und msgget legt die Warteschlange an.
- Der Datensatz der Warteschlangenkennsätze in Figur 3 enthält einen Anzeiger dafür, ob die spezifische Warteschlange lokal, L, zu dem Knoten ist, an dem sich die Tabelle der Warteschlangenkennsätze befindet, oder ob sie an einem entfernten Knoten, R, angeordnet ist. Das Format des restlichen Eintrags in der Tabelle der Warteschlangenkennsätze ist eine Funktion des lokalen/- entfernten Anzeigers. Wenn die Warteschlange lokal ist, dann enthält LKEY den lokalen Warteschlangenschlüssel; und LMTYPE ist der Wert des Nachrichtentypanzeigers, der für diese Warteschlange zuletzt benutzt wurde.
- Bei entfernten Warteschlangen enthält RNODE die Knoten-id und RMODE MSQID die Nachrichtenwarteschlangen-id am entfernten Knoten. Das Feld RNODE BOOTCNT enthält eine Nummer, die den Status des Leistungszyklus beim entfernten Knoten anzeigt.
- Figur 4 erläutert den Inhalt-eines Eintrags der Nachrichtenwarteschlange. MTYPE enthält den Typ der Nachricht und MSGPTR einen Zeiger auf den Nachrichtentext.
- Figur 5 ist ein Flußdiagramm, das die logischen Abläufe erläutert, die während IPC erfindungsgemäß ausgeführt werden. Wenn ein Prozeß am Knoten LOCNODE einen Informationsaustausch initialisiert, dann gibt er einen Systemaufruf msgget heraus, der einen LKEY als Eingabe liefert, wie es bei Block 80 dargestellt ist. Dieser Schlüssel ist das Argument für eine Suchfunktion in der kernresidenten KMT von LOCNODE. Die KMT wird durchsucht, Block 82. Wenn ein Gegenstück gefunden wird, Block 84, dann bestimmt die IPC-Logik, Block 86, ob eine Datenübertragung zwischen LOCNODE und REMNODE existiert (bei dieser Diskussion wird hier angenommen, das RNODE die Knoten-id für REMNODE enthält). Wenn es keine existierende Datenübertragung gibt, dann wird eine eingerichtet, Block 88, und der in der KMT gefundene zugehörige Schlüssel RKEY wird an seinen zugehörigen Knoten REMNODE geschickt, Block 90.
- Wenn für den LKEY, der zum Aufruf von msgget benutzt wurde, in der KMT kein Eintrag gefunden wurde, dann wird angenommen, daß die Nachrichtenwarteschlange örtlich ist, Block 92, und der Informationsaustausch erfolgt auf die übliche Weise.
- Bei Block 94 empfängt das msgget-Transaktionsprogramm von REMNO- DE RKEY und durchsucht dann, Block 96, die Warteschlangenkennsätze bei REMNODE. Wenn kein Gegenstück gefunden wurde, Block 98, dann existiert eine Febierbedingung, und dies wird bei Block 100 angezeigt. Wenn die Warteschlangenkennsätze von REMNODE einen zu RKEY passenden Eintrag enthalten, dann wird an LOCNODE eine MSQID mit der Bootzählung von RENNODE, RNODE BOOTCNT, Block 102, zurückgeschickt.
- Nach der Rückkehr zu LOCNODE wird, wie bei Block 104 dargestellt, ein Warteschlangen-Kennsatzeintrag im Format R (siehe Fig. 3) der Liste LOCNODE-Warteschlangenkennsätze hinzugefügt, und die MSQID des örtlichen Knotens wird an den Aufrufer zurückgeschickt. Der aufrufende Prozeß führt dann msgsnd aus, und es gilt die in Fig. 5B dargestellte Logik.
- Bei LOCNODE wird MSQID, Block 110, dazu benutzt, in der Liste der Warteschlangenkennsätze von LOCNODE zu indizieren, Block 112. Bei Block 114 wird eine Bestimmung durchgeführt, ob REMNODE (RNODE im Warteschlangenkennsatz) schon mit LOCNODE verbunden ist. Wenn nicht, wird eine Verbindung hergestellt, Block 116, und LOCNODE msgsnd veranlaßt, daß der Nachrichtentext, MSQID RNODE BOOTCNT und ein MTYPE an REMNODE, Block 118, abgeschickt werden.
- Bei REMNODE empfängt sein msgsnd-Transaktionsprogramm MSQID, BOOTCNT und MTYPE bei Block 120. REMNODE empfängt diese Daten und vergleicht zuerst, Block 122, die empfangene mit der bei REMNODE aktuellen Bootzählung. Wenn sie nicht zusammenpassen, dann existiert eine Fehlerbedingung, Block 124, und sie wird an LOCNODE zurückgeschickt. Wenn die Bootzählungswerte passen, dann benutzt das msgsnd-Transaktionsprogramm von REMNODE MSQID, um einen Warteschlangenkennsatz auszuwählen und den Zeiger des Nachrichtentextes MSGPTR zusammen mit dem MTYPE, Block 126, in seiner Nachrichtenwarteschlange unterzubringen. REMNODE antwortet LOCNODE, Block 128, der dann zu seinem Aufrufer, zum erfolgreichen Abschluß zurückkehrt.
- Fig. 5C erläutert den Vorgang des msgrcv-Systemaufrufs. Bei LOCNODE empfängt msgrcv eine MSQID und MTYPE, Block 140. Es benutzt die MSQID, um in seiner Liste der Warteschlangenkennsätze zu indizieren und den richtigen Warteschlangenkennsatz zu finden. Unter Verwendung der RNODE-Information, die im Kennsatz enthalten ist, bestimmt es, Block 144, ob mit REMNODE eine Verbindung zum Informationsaustausch existiert, und wenn nicht, stellt er eine Verbindung her, Block 146. Bei Block 148 werden MSQID, RNODE BOOTCNT und MTYPE über den aufgebauten Datenübermittlungsabschnitt an RENNODE geschickt.
- Nachdem das msgrcv-Transaktionsprogramm von REMNODE diese Information empfangen hat, Block 150, vergleicht es zuerst die Bootzählungswerte (empfangene und aktuelle), Block 152. Wenn die Bootzählungen nicht zueinander passen, dann wird eine Fehlerbedingung angezeigt, Block 154, und es erfolgt eine Rückkehr zu LOCNODE.
- Wenn die Bootzählungen zueinander passen, dann benutzt die Logik des msgrcv-Transaktionsprogramms von REMNODE, Block 156, die empfangene MSQID, um einen Warteschlangenkennsatz auszuwählen. Die Logik prüft dann die Nachrichteneinträge der Warteschlange um zu bestimmen, ob es eine Nachricht mit dem passenden MTYPE gibt, Block 158. Wenn in der Nachrichtenwarteschlange von REMNODE keine Nachricht einen passenden MTYPE hat, dann erwartet die Logik die Ankunft einer Nachricht, Block 160. Wenn eine Nachricht mit einem passenden MTYPE gefunden wird, dann wird bei Block 162 der Zeiger des Nachrichtentextes über die gleiche Datenübertragung an LOCNODE zurückgeschickt, die oben schon aufgebaut wurde. LOCNODE schickt bei Block 164 den Nachrichtentext zu seinem Aufrufer zurück.
- Fig. 6 erläutert unter Verwendung eines spezifischen Satzes von hypothetischen Umständen die Logik, die in Verbindung mit den Figuren 5A, B und C beschrieben wird. Es wird angenommen, daß es bei LOCNODE ein Rahmen-Befehlsprogramm gibt, das Benutzer aufrufen, um Konferenzräume zu planen. Der Rahmenbefehl gibt für seinen LKEY 71000 eine msgget aus, damit er für die IPC-Nachrichtenwarteschlange des Planungsdämons eine MSQID erhält. Es wird angenommen, daß der Netzwerkverwalter bestimmt hat, daß Anforderungen von Konferenzräumen von LOCNODE vom Dämon in REMNODE bedient werden, und daß der Schlüssel für die Warteschlange des Dämons in REMNODE 67000 ist. Diese Information ist in die IPC- KMT des Kerns von LOCNODE geladen worden.
- 1. get_room ruft MSGGET mit Schlüssel 71000 auf.
- 2. MSGGET fragt bei der KNT von LOCNODE nach dem Schlüssel 71000 nach.
- 3. Die KMT zeigt an, daß där Schlüssel 71000 im RNODE REMNODE zum RKEY 67000 neu abgebildet worden ist.
- 4. MSGGET weiß nun, daß es in REMNODE nach Schlüssel 67000 suchen muß.
- 5. MSGGET findet oder erstellt eine SNA-Verbindung mit REMNODE und sendet eine Netzwerknachricht, die eine MSQID für Schlüssel 67000 abfordert.
- 6. Das MSGGET-Transaktionsprogramm in REMNODE findet den Kennsatz der Nachrichtenwarteschlange für diejenige Warteschlange, deren Schlüssel 67000 ist; in diesem Falle ist MSQID 2;
- 7. das MSGGET-Transaktionsprogramm in REMNODE sendet an MSGGET in LOCNODE eine Netzwerkantwort mit der Feststellung, daß MSQID 2 ist;
- 8. MSGGET fügt seiner Liste der Warteschlangenkennsätze einen Eintrag hinzu. Der Kennsatzeintrag enthält unter anderem REMNODE in RNODE, wobei 2 die RNODE MSQID ist, und ein Etikett R, das angibt, daß dies ein lokaler "Ersatz" für einen entfernten Warteschlangenkennsatz ist. In diesem Beispiel befindet sich der Ersatzkennsatz für die entfernte Warteschlange in Fach 1 der Liste der Warteschlangenkennsätze von LOCNODE, so daß die LOCNODE MSQID 1 ist;
- 9. MSGGET schickt MSQID=1 an seinen Aufrufer zurück.
- 10. get_room benutzt diese MSQID dazu, IPC-Nachrichten an den Dämon der Konferenzräume zu schicken. Die Information im Ersatz des Warteschlangenkennsatzes teilt LOCNODE mit, wohin er die Nachrichten zu senden hat.
- Das Folgende ist eine Pseudocode-Darstellung des logischen Ablaufs, wie er im Zusammenhang mit den Fig. 5A, B, C und 6 beschrieben wird:
- Die Zuordnung der Warteschlangenschlüssel muß so verwaltet werden, daß für "wohlbekannte" Warteschlangen, also solche, die wahrscheinlich von vielen Mandanten benutzt werden, keine doppelten Schlüssel angelegt werden. Gemäß der vorliegenden Erfindung wird eine Strategie zur Verfügung gestellt, mit der Erzeuger von Anwendungsprojekten in die Lage versetzt werden, global eindeutige Schlüssel anzulegen, ohne daß die Notwendigkeit besteht, die zugeordneten Schlüssel extern zu registrieren. Das Hauptelement dieser Strategie ist die Verwendung eines Warteschlangennamens mit 14 alphanumerischen Zeichen im Eintrag des Warteschlangenprofils (Fig. 1, 52).
- Die Anwendungsentwickler wählen Namen mit 14 Zeichen, die sich selbst eindeutig darstellen. Jeder Eintrag im Warteschlangenprofil hat die folgenden Felder: QNAME, LKEY, RNODE, PKEY, wie in Fig. 1 dargestellt.
- Die Bibliotheksroutine create_ipc_prof (QNAME, LKEY, RKEY, NICK- NAME) legt ein Warteschlangenprofil an. Der Aufrufer stellt den Namen zur Verfügung, und die Routine legt einen Eintrag im Warteschlangenprofil an, ordnet ihm einen eindeutigen lokalen Schlüssel zu und schickt den lokalen Schlüssel an den Aufrufer zurück. Nachfolgend stellt der Netzwerkverwalter Daten für RNODE und RKEY zur Verfügung.
- Es wird angenommen, daß eine verteilte Anwendung aus einem Serverdämon und einem Befehlsprogramm besteht, das Anforderungen an das Dienstprogramm hat. Das Dienstprogramm befindet sich an einem spezifischen Netzwerkknoten; das Befehlsprogramm kann an jedem beliebigen von mehreren Knoten im Netzwerk betrieben werden. Die Installation und der Betrieb einer solchen Anwendung werden im folgenden Beispiel erläutert.
- An der Stelle, wo der Dämon betrieben werden soll, ruft das Installationsprogramm der Anwendung create_ipc_prof(3) auf, was einen Warteschlangennamen von "ACMEsfwr032686" vergibt. Das von create_ipc_prof(3) angelegte Profil enthält:
- Name "ACMEsfwr032686"
- lokaler Schlüssel Ein Wert, der von create_ipc_prof(3) aus dem Bereich 0x30000 bis 0xFFFFF ausgewählt wurde, der mit einem beliebigen anderen Profil an diesem Knoten nicht in Konflikt kommt
- entfernter Knoten Null
- entfernter Schlüssel 0
- An jeder Stelle, an der das Befehlsprogramm betrieben werden soll, ruft das Installationsprogramm der Anwendung create_ipc_prof(3) auf, das einen Warteschlangennamen von "ACMEsfwr032686" vergibt. Das von create_ipc_prof(3) angelegte Profil enthält:
- Name "ACMFsfwr032686"
- örtlicher Schlüssel Ein Wert, der von create_ipc_prof(3) aus dem Bereich 0x30000 bis 0xFFFFF ausgewählt wird, der mit einen anderen beliebigen Profil an diesem Knoten nicht in Konflikt kommt.
- entfernter Knoten Null
- entfernter Schlüssel 0
- Der Netzwerkverwalter ist über das Modifizieren der Profile an den Befehlsknoten unterrichtet, damit sie enthalten:
- entfernter Knoten Der Knoten der Gottheit
- entfernter Schlüssel Der örtliche Schlüssel der Warteschlange am Knoten der Gottheit
- Wenn der Dämon anläuft, ruft sie find_ipc_prof(3) auf und gibt einen Warteschlangennamen "ACMEsfwr032686" vor, damit der mit diesem Namen verbundene Schlüssel gefunden wird. Dann ruft sie msgget (Schlüssel,0) auf, um für die Warteschlange eine id zu erhalten.
- Ein Warteschlangenname mit 14 Zeichen läßt den Softwareentwicklern bei der Auswahl von Warteschlangennamen sehr viele Wahlfreiheiten. Sogar ohne Zusammenarbeit zwischen Anwendungsentwicklern besteht eine sehr geringe Wahrscheinlichkeit, daß ein von einem Entwickler sorgfältig ausgewählter Name mit einem von einem anderen sorgfältig ausgewählten Namen kollidiert. Ein vorsichtiger Entwickler könnte jedoch seinen Entwurf so wählen, daß der Fall einer Kollision eintritt. Eine beispielhafte Strategie für den Umgang mit solchen Kollisionen besteht darin:
- * Der bevorzugte Warteschlangenname wird im Anwendungsprogramm fest codiert, aber es kann durch ein Befehlsargument sowohl des Dämons wie den Befehlsprogrammen eine Überschreibkette zur Verfügung gestellt werden.
- * Wenn ein Dämon oder ein Befehlsprogramm installiert werden, dann benutzt es create_ipc_prof(3) dazu, die notwendigen Warteschlangenprofile anzulegen. Wenn das Anlegen wegen einer Namenkollision mißlingt, dann wird dem Verwalter ein eindeutiger Warteschlangenname abgefordert. Das Installationsprogramm benutzt dann diesen Warteschlangennamen, um das Profil anzulegen.
- * Das Installationsprogramm und/oder die Dokumentation weisen den Verwalter an sicherzustellen, daß der Dämon und das Befehlsprogramm immer mit dem Argument des Warteschlangennamens aufgerufen werden.
- Es wird nun die Verfahrensweise beschrieben, die dafür eingerichtet wurde, daß eine korrekte Nachrichtenvermittlung erfolgt. Bei einer dezentralen Anwendung, wie sie in der oben erwähnten Quelle von Bach beschrieben ist, wird der Parameter MTYPE geeignet festgelegt, damit der Kern die erste Nachricht eines gegebenen Typs zurückschicken kann. Wenn keine Nachrichten in der Warteschlange dem Typ genügen, dann legt der Kern den Vorgang schlafen. Die Vorgänge können zusammenarbeiten, damit sie an einer Nachrichtenwarteschlange mehrfache Kanäle einrichten, wodurch jeder Vorgang Nachrichten mit spezifischen Typen in der Reihenfolge ihrer Ankunft extrahieren kann, wobei der Kern die richtige Reihenfolge aufrechterhält.
- In einer Netzwerkumgebung mit verteilten Diensten ist es jedoch für mehrere Anforderer möglich, sich gleichzeitig mit demselben Dienstprogramm zu befassen. Die vorliegende Erfindung bietet unter Verwendung des Nachrichtentyps eine Entschachtelungsfunktion von Antwortnachrichten.
- MTYPE-Werte sollen als eindeutig zugeordnet werden, indem sie im Kennsatz der Nachrichtenwarteschlange (Fig. 3) einen MTYPE-Wert von 32 Bit zur Verfügung stellen, der dem letzten verwendeten MTYPE-Wert entspricht. Ein neuer Befehl zum Aufruf des Nachrichtensteuersystems (msgctl) veranlaßt, daß der aktuelle Wert des Nachrichtentyps einer Warteschlange zurückgeschickt wird. Jedesmal, wenn MTYPE an einen Vorgang (Fig. 5B, Block 128) zurückgeschickt wird, wird es nachinkrementiert.
- Da es für Anforderungen und Antworten effizienter ist, durch die gleiche Warteschlange zu laufen, erweitert die für MTYPE bei der Entschachtelung von Vorwärts-Rückwärts-Warteschlangen getroffene Vereinbarung den Netzwerkdurchsatz noch mehr.
- Das folgende Scenario erläutert ein potentielles Problem in Form eines Beispiels. In den Vorgang des Anlegens einer Warteschlange, deren Kennzeichnungsinformation in das erste Fach der Warteschlangenkennsätze eingeht, wird ein Dienstprogramm eingeschaltet. Ein Mandant vollführt eine msgget, wobei er eine MSQID empfängt. In der Zwischenzeit durchläuft das Dienstprogramm einen Leistungszyklus. Zu einem etwas späteren Zeitpunkt legt ein Vorgang in diesem Dienstprogramm eine weitere Warteschlange an, wobei er deren Kennsatzinformation in das erste Fach der Warteschlangenkennsätze plaziert. Der Mandantenvorgang vollführt dann eine msgsnd unter Verwendung der ursprünglichen MSQID. Die Nachricht vom Mandanten geht dann nicht in die Warteschlange, die der Mandant erwartet.
- Mit der Verfahrensweise der vorliegenden Erfindung wird dieses Problem vermieden, weil immer dann, wenn ein Mandant eine Nachricht absendet, ein Vergleich der Bootzählungen vorgenommen wird; und wenn die Bootzählungen nicht gleich sind, dann wird der Mandant über die Fehlerbedingung informiert. Es ist wieder Bezug zu nehmen auf Fig. 5B, Blöcke 122, 124, und 50, Blöcke 152, 154.
- Jeder Knoten enthält im Superblock seines Grundgerätes (Fig. 1, 54) einen Zähler, BOOTCNT, der eine Anzeige für den Einschaltstatus des Dienstprogramms ist. Dieser Zähler wird jedesmal dann inkrementiert, wenn das Dienstprogramm ausgeschaltet und wieder eingeschaltet wird. Dieser Zähler wird bei Nachrichtenvorgängen benutzt, wie etwa den in Fig. 5B und 5C beschriebenen, die einen Kennsatz von Nachrichtenwarteschlangen benutzen, wobei dann sichergestellt wird, daß sich das Dienstprogramm in demselben Zustand befindet, in dem es war, als es den Kennsatz der Nachtichtenwarteschlange herausgab.
- Zusammenfassend stellt die vorliegende Erfindung eine auf Kernebene zu betreibende Verfahrensweise zur Prozeßkommunikation zwischen Prozessoren zur Verfügung, die sich an beliebigen Knoten in einem Mehrfachknoten-Netzwerk befinden. Der Informationsaustausch wird über Nachrichten durchgeführt, die in mit Schlüssein gekennzeichneten Nachrichtenwarteschlangen untergebracht sind, die sich an einem beliebigen Knoten innerhalb des Netzwerkes befinden können.
- Auf der Anwendungsebene gibt es keine Notwendigkeit, daß der Knotenstandort der Nachrichtenwarteschlange bekannt ist, weil die Schlüsselabbildungstabellen und ihre oben beschriebene Verwendung die Auflösung des von der Anwendung zur Verfügung gestellten Schlüssels in eine aktuelle Adresse einer Nachrichtenwarteschlange ermöglicht, die von Systemaufrufen zur Nachrichtenhandhabung benutzt wird. Die Unversehrtheit der Nachrichtenübertragung wird durch den Schritt des Bootzäblungsvergleichs in den erforderlichen Systemaufrufen verbessert. Das Multiplexen von Nachrichten für verschiedene Knoten wird dadurch verbessert, daß in den Kennsatzeinträgen der Warteschlangen ein ausführlicher beschreibender MTYPE zur Verfügung gestellt wird. Die beschriebene Übereinkunft zur Vergabe von Warteschlangennamen beseitigt im wesentlichen das Risiko von Konfliktfällen, d.h. der Verwendung des gleichen Namens durch unterschiedliche Anwendungen, bei Nachrichtenwarteschlangen in der Netzwerkumgebung mit verteilten Diensten.
Claims (5)
1. Ein Verfahren zur Unterstützung von Datenübertragungen
zwischen Benutzeranwendungen, die an Prozessoren ablaufen, die
an einem oder mehreren knoten innerhalb eines Netzwerkes
angeordnet sind, wobei Nachrichtenwarteschlangen benutzt
werden, deren aktuelle Knotenstandorte für die
Benutzeranwendungen transparent sind, gekennzeichnet durch die
Schritte:
Aufrechterhalten einer Schlüsselabbildungstabelle, die
knoteneindeutige Warteschlangenschlüssel, die den an jedem
Knoten laufenden Anwendungen zugeordnet sind, mit dem
aktuellen Knotenstandort der Warteschlange und den Schlüsseln
der Nachrichtenwarteschlangen verbindet, im Speicher an
jedem Knoten;
Zugreifen auf eine Schlüsselabbildungstabelle mit einem von
der Anwendung bereitgestellten Schlüssel, um den Knoten und
den Schlüssel einer Nachrichtenwarteschlange zu erhalten,
und Einrichten einer Datenübertragung zwischen dem
Anwendungsknoten und dem Knoten der Nachrichtenwarteschlange.
2. Das Verfahren gemäß Anspruch 1, das zusätzlich den Schritt
umfaßt:
Bestimmen, ob der Knoten der Nachrichtenwarteschlange
während eines Zeitraumes zwischen der Rücksendung eines
Nachrichtenwarteschlangen-Kennsatzes an einen Knoten und seiner
Verwendung durch den Knoten einen Leistungszyklus
durchgemacht hat.
3. Das Verfahren gemäß Anspruch 1, das die zusätzlichen
Schritte umfaßt:
Verbinden eines eindeutigen Typenwertes mit jeder
Warteschlange;
Nachinkrementieren des eindeutigen Typenwertes, wenn eine
Anwendung einen eindeutigen Typenwert abfordert; und
Benutzen des Typenwertes, um eine gewünschte Nachricht aus
einer Vielzahl von Nachrichten in einer
Nachrichtenwarteschlange auszuwählen.
4. Ein Netzwerkverwaltungssystem, mit dem die Knotenstandorte
von Nachrichtenwarteschlangen Benutzeranwendungsprogrammen
in einem Netzwerk mit verteilten Diensten (10) transparent
gemacht werden, wobei das Netzwerk Prozessoren (40) umfaßt,
von denen sich jeder an einem unterschiedlichen Knoten (A,
B, C) befinden kann, wobei jeder Prozessor (40)
speicherresidente Systembetriebsmittel (46) und Programme (44)
umfaßt, mit denen Nachrichtenwarteschlangen angelegt werden
und auf diese zugegriffen wird, und wobei jeder Prozessor
(40) in der Lage ist, eine Vielzahl von
Benutzeranwendungsprogrammen (42) auszuführen, in denen der
Informationsaustausch zwischen den Prozessoren (40) über Warteschlangen
erfolgt, die an jedem beliebigen Knoten im Netzwerk (10)
angeordnet sind, wobei das Netzwerkverwaltungssystem
dadurch gekennzeichnet ist, daß das System umfaßt:
Bibliotheksroutinenmittel, die von jedem Knoten aus zur
Zuordnung von knoteneindeutigen Warteschlangenschlüsseln
(LKEY) zu einem Warteschlangennamen (QNAME) aufrufbar sind,
der von jedem Benutzeranwendungsprogramm zur Verfügung
gestellt wird;
Tabellenlademittel (52), die beim Prozessoranlauf betrieben
werden, damit an jedem Knoten (A, B, C) eine kernresidente
Abbildungstabelle (KMT) zur Verfügung steht, die Einträge
hat, mit denen die zugeordneten knoteneindeutigen Schlüssel
(LKEY) mit den Knotenstandorten der
Nachrichtenwarteschlangen (RNODE) und den vom Benutzeranwendungsprogramm
bereitgestellten
Schlüsseln (RKEY) verbunden werden; und Mittel
zum Annehmen eines von einem Benutzeranwendungsprogramm
bereitgestellten Schlüssels (RKEY), das einen zugehörigen
Knotenstandort einer Nachrichtenwarteschlange auffindet
(RNODE) und eine Datenübertragung zwischen dem Knoten des
Benutzeranwendungsprogramms (A, B, C) und einem zugehörigen
Knotenstandort der Nachrichtenwarteschlange (RNODE)
errichtet, damit ein Nachrichtenvorgang durchgeführt wird.
5. Ein System, wie es mit Anspruch 4 belegt wird, das Mittel
zum Bestimmen umfaßt, ob ein Knotenstandort einer
Nachrichtenwarteschlange während eines Zeitraumes zwischen der
Rücksendung eines Nachrichtenwarteschlangen-Kennsatzes an
den Knoten einer Benutzeranwendung und seiner Verwendung am
Benutzeranwendungs knoten einen Leistungszyklus durchgemacht
hat.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/014,888 US5133053A (en) | 1987-02-13 | 1987-02-13 | Interprocess communication queue location transparency |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3852324D1 DE3852324D1 (de) | 1995-01-19 |
DE3852324T2 true DE3852324T2 (de) | 1995-05-24 |
Family
ID=21768375
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3852324T Expired - Fee Related DE3852324T2 (de) | 1987-02-13 | 1988-01-26 | Verfahren und System zur Netzwerkverwaltung. |
Country Status (4)
Country | Link |
---|---|
US (1) | US5133053A (de) |
EP (1) | EP0278316B1 (de) |
JP (1) | JPS63201860A (de) |
DE (1) | DE3852324T2 (de) |
Families Citing this family (75)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0325384B1 (de) * | 1988-01-15 | 1993-09-29 | Quantel Limited | Datenverarbeitung und -übertragung |
US5345587A (en) | 1988-09-14 | 1994-09-06 | Digital Equipment Corporation | Extensible entity management system including a dispatching kernel and modules which independently interpret and execute commands |
US5117351A (en) * | 1988-10-21 | 1992-05-26 | Digital Equipment Corporation | Object identifier generator for distributed computer system |
US5551035A (en) * | 1989-06-30 | 1996-08-27 | Lucent Technologies Inc. | Method and apparatus for inter-object communication in an object-oriented program controlled system |
EP0405829B1 (de) * | 1989-06-30 | 1998-04-15 | AT&T Corp. | Objektorientierte Softwaresystembauweise |
JPH0362257A (ja) * | 1989-07-31 | 1991-03-18 | Toshiba Corp | ネットワークモニタリングシステム |
ATE179811T1 (de) * | 1989-09-08 | 1999-05-15 | Auspex Systems Inc | Betriebssystemaufbau mit mehreren verarbeitungseinheiten |
AU631749B2 (en) * | 1990-09-14 | 1992-12-03 | Digital Equipment Corporation | System and method for communication between windowing environments |
JPH04130950A (ja) * | 1990-09-21 | 1992-05-01 | Toshiba Corp | ネットワークシステム |
EP0552288A1 (de) * | 1990-10-03 | 1993-07-28 | Thinking Machines Corporation | Paralleles rechnersystem |
US5673394A (en) * | 1990-10-31 | 1997-09-30 | Microsoft Corporation | Method of sharing memory between an operating system and an application program |
EP0490595B1 (de) * | 1990-12-14 | 1998-05-20 | Sun Microsystems, Inc. | Verfahren zum Betrieb zeitkritischer Prozesse in einer Fenstersystemumgebung |
US5617547A (en) * | 1991-03-29 | 1997-04-01 | International Business Machines Corporation | Switch network extension of bus architecture |
US5347633A (en) * | 1991-04-30 | 1994-09-13 | International Business Machines, Inc. | System for selectively intercepting and rerouting data network traffic |
FR2679351B1 (fr) * | 1991-07-15 | 1995-01-27 | Bull Sa | Systeme d'exploitation pour dispositif universel de couplage d'un bus d'ordinateur a une liaison specifique d'un reseau. |
JP3116443B2 (ja) * | 1991-08-30 | 2000-12-11 | ソニー株式会社 | ソケット通信ログ蓄積装置 |
US5257384A (en) * | 1991-09-09 | 1993-10-26 | Compaq Computer Corporation | Asynchronous protocol for computer system manager |
US5913922A (en) * | 1991-09-16 | 1999-06-22 | Pitney Bowes Inc. | Method of transmitting messages between software processes in a multitasking data processing system |
US5287434A (en) * | 1991-10-28 | 1994-02-15 | Monarch Marking Systems, Inc. | Barcode identification system spooler |
US5313638A (en) * | 1992-03-24 | 1994-05-17 | International Business Machines Corp. | Method using semaphores for synchronizing communication between programs or processes resident in a computer system |
FR2689267B1 (fr) * | 1992-03-27 | 1994-05-06 | Telemecanique | Procede de reconnaissance de donnees circulant sur un reseau de transmission de donnees et dispositif pour la mise en óoeuvre de ce procede. |
US5611049A (en) * | 1992-06-03 | 1997-03-11 | Pitts; William M. | System for accessing distributed data cache channel at each network node to pass requests and data |
US6026452A (en) * | 1997-02-26 | 2000-02-15 | Pitts; William Michael | Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data |
US5577202A (en) * | 1992-08-24 | 1996-11-19 | Trw Inc. | Message handling system for automated gateway between first and second handling systems wherein first envelope is added to a second envelope respectively without changing text |
US5437036A (en) * | 1992-09-03 | 1995-07-25 | Microsoft Corporation | Text checking application programming interface |
US5490252A (en) * | 1992-09-30 | 1996-02-06 | Bay Networks Group, Inc. | System having central processor for transmitting generic packets to another processor to be altered and transmitting altered packets back to central processor for routing |
FR2698461B1 (fr) * | 1992-11-23 | 1995-01-13 | Bull Sa | Dispositif de traitement de l'information permettant la gestion d'une ressource informatique par un système d'administration. |
US5386568A (en) * | 1992-12-01 | 1995-01-31 | Yamaha Corporation | Apparatus and method for linking software modules |
US6718399B1 (en) * | 1993-05-21 | 2004-04-06 | Candle Distributed Solutions, Inc. | Communications on a network |
US5613090A (en) * | 1993-10-05 | 1997-03-18 | Compaq Computer Corporation | Computer system for disparate windowing environments which translates requests and replies between the disparate environments |
US5802312A (en) * | 1994-09-27 | 1998-09-01 | Research In Motion Limited | System for transmitting data files between computers in a wireless environment utilizing a file transfer agent executing on host system |
US6085234A (en) * | 1994-11-28 | 2000-07-04 | Inca Technology, Inc. | Remote file services network-infrastructure cache |
US6247064B1 (en) * | 1994-12-22 | 2001-06-12 | Unisys Corporation | Enqueue instruction in a system architecture for improved message passing and process synchronization |
US5555396A (en) * | 1994-12-22 | 1996-09-10 | Unisys Corporation | Hierarchical queuing in a system architecture for improved message passing and process synchronization |
US5563878A (en) * | 1995-01-05 | 1996-10-08 | International Business Machines Corporation | Transaction message routing in digital communication networks |
US5724508A (en) * | 1995-03-09 | 1998-03-03 | Insoft, Inc. | Apparatus for collaborative computing |
US7058067B1 (en) | 1995-03-13 | 2006-06-06 | Cisco Technology, Inc. | Distributed interactive multimedia system architecture |
US5838683A (en) | 1995-03-13 | 1998-11-17 | Selsius Systems Inc. | Distributed interactive multimedia system architecture |
US5781787A (en) * | 1995-04-21 | 1998-07-14 | Lockheed Martin Corporation | Parallel program execution time with message consolidation |
US6097882A (en) * | 1995-06-30 | 2000-08-01 | Digital Equipment Corporation | Method and apparatus of improving network performance and network availability in a client-server network by transparently replicating a network service |
US5812767A (en) * | 1995-07-28 | 1998-09-22 | International Business Machines Corporation | System for user registering an address resolution routine to provide address resolution procedure which is used by data link provider interface for resolving address conflicts |
US5754856A (en) * | 1995-08-30 | 1998-05-19 | Candle Distributed Solutions, Inc. | MVS/ESA message transport system using the XCF coupling facility |
KR0150072B1 (ko) * | 1995-11-30 | 1998-10-15 | 양승택 | 병렬처리 컴퓨터 시스템에서의 메모리 데이타 경로 제어장치 |
US5745781A (en) * | 1995-12-26 | 1998-04-28 | International Business Machines Corporation | Memoryless communications adapter including queueing and matching primitives for scalable distributed parallel computer systems |
US5790789A (en) * | 1996-08-02 | 1998-08-04 | Suarez; Larry | Method and architecture for the creation, control and deployment of services within a distributed computer environment |
US5781703A (en) * | 1996-09-06 | 1998-07-14 | Candle Distributed Solutions, Inc. | Intelligent remote agent for computer performance monitoring |
WO1998027506A2 (en) * | 1996-12-17 | 1998-06-25 | Inca Technology, Inc. | Ndc consistency reconnect mechanism |
US6167446A (en) * | 1997-11-03 | 2000-12-26 | Inca Technology, Inc. | Automatically configuring network-name-services |
SE511098C2 (sv) * | 1997-12-08 | 1999-08-02 | Ericsson Telefon Ab L M | Kommunikationssystem och förfarande för att sända meddelanden i ett kommunikationssystem |
US6310888B1 (en) * | 1997-12-30 | 2001-10-30 | Iwork Software, Llc | System and method for communicating data |
US6308167B1 (en) * | 1998-04-09 | 2001-10-23 | Compaq Computer Corporation | Computer system using a queuing system and method for managing a queue and heterogeneous data structures |
US7305473B2 (en) * | 1999-05-28 | 2007-12-04 | The Coca-Cola Company | Provision of transparent proxy services to a user of a client device |
ATE390788T1 (de) | 1999-10-14 | 2008-04-15 | Bluearc Uk Ltd | Vorrichtung und verfahren zur hardware-ausführung oder hardware-beschleunigung von betriebssystemfunktionen |
US7237022B1 (en) * | 2000-06-29 | 2007-06-26 | Microsoft Corporation | Suspension and reinstatement of reference handles |
US7383355B1 (en) | 2000-11-01 | 2008-06-03 | Sun Microsystems, Inc. | Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects |
US7089564B2 (en) * | 2001-02-22 | 2006-08-08 | International Business Machines Corporation | High-performance memory queue |
US7068604B2 (en) * | 2001-08-23 | 2006-06-27 | International Business Machines Corporation | Managing memory resident queues to control resources of the systems using the queues |
US6901533B2 (en) * | 2001-08-23 | 2005-05-31 | International Business Machines Corporation | Reconstructing memory residents queues of an inactive processor |
US20030126109A1 (en) * | 2002-01-02 | 2003-07-03 | Tanya Couch | Method and system for converting message data into relational table format |
US8041735B1 (en) | 2002-11-01 | 2011-10-18 | Bluearc Uk Limited | Distributed file system and method |
US7457822B1 (en) | 2002-11-01 | 2008-11-25 | Bluearc Uk Limited | Apparatus and method for hardware-based file system |
US20120190441A1 (en) * | 2003-03-05 | 2012-07-26 | Sierra Design Group | Gaming Platform |
US8136155B2 (en) * | 2003-04-01 | 2012-03-13 | Check Point Software Technologies, Inc. | Security system with methodology for interprocess communication control |
JP2005135382A (ja) * | 2003-08-19 | 2005-05-26 | Toshiba Corp | イベントベースの通知を有する共有メモリベースのプロセス間通信キューテンプレートのシステムおよび方法 |
US20050080759A1 (en) * | 2003-10-08 | 2005-04-14 | International Business Machines Corporation | Transparent interface to a messaging system from a database engine |
KR100716169B1 (ko) * | 2005-05-06 | 2007-05-10 | 삼성전자주식회사 | 네트워크 관리 시스템에서의 메시지 처리 장치 및 방법 |
JP5464449B2 (ja) * | 2011-04-06 | 2014-04-09 | 日本電気株式会社 | 障害によるリブートを考慮した処理部間の不整合検出方法並びに共有装置及びクラスタシステム |
US9116761B2 (en) * | 2011-09-29 | 2015-08-25 | Oracle International Corporation | System and method for preventing single-point bottleneck in a transactional middleware machine environment |
US9690638B2 (en) * | 2011-09-29 | 2017-06-27 | Oracle International Corporation | System and method for supporting a complex message header in a transactional middleware machine environment |
US9063974B2 (en) | 2012-10-02 | 2015-06-23 | Oracle International Corporation | Hardware for table scan acceleration |
WO2015096120A1 (en) * | 2013-12-27 | 2015-07-02 | Intel Corporation | Techniques for implementing a secure mailbox in resource-constrained embedded systems |
US9898414B2 (en) | 2014-03-28 | 2018-02-20 | Oracle International Corporation | Memory corruption detection support for distributed shared memory applications |
US10467139B2 (en) | 2017-12-29 | 2019-11-05 | Oracle International Corporation | Fault-tolerant cache coherence over a lossy network |
US10452547B2 (en) | 2017-12-29 | 2019-10-22 | Oracle International Corporation | Fault-tolerant cache coherence over a lossy network |
US11893267B2 (en) | 2022-01-14 | 2024-02-06 | Bank Of America Corporation | Data flow control and routing using machine learning |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4266271A (en) * | 1978-10-10 | 1981-05-05 | Chamoff Martin E | Reconfigurable cluster of data-entry terminals |
US4814979A (en) * | 1981-04-01 | 1989-03-21 | Teradata Corporation | Network to transmit prioritized subtask pockets to dedicated processors |
US4412285A (en) * | 1981-04-01 | 1983-10-25 | Teradata Corporation | Multiprocessor intercommunication system and method |
US4719622A (en) * | 1985-03-15 | 1988-01-12 | Wang Laboratories, Inc. | System bus means for inter-processor communication |
US4694396A (en) * | 1985-05-06 | 1987-09-15 | Computer X, Inc. | Method of inter-process communication in a distributed data processing system |
EP0201063B1 (de) * | 1985-05-06 | 1993-07-07 | Computer X, Inc. | Methode zur Lokalisierung von Prozessen in einem verteilten Datenverarbeitungssystem |
US4706080A (en) * | 1985-08-26 | 1987-11-10 | Bell Communications Research, Inc. | Interconnection of broadcast networks |
-
1987
- 1987-02-13 US US07/014,888 patent/US5133053A/en not_active Expired - Lifetime
- 1987-11-17 JP JP62288623A patent/JPS63201860A/ja active Granted
-
1988
- 1988-01-26 EP EP88101090A patent/EP0278316B1/de not_active Expired - Lifetime
- 1988-01-26 DE DE3852324T patent/DE3852324T2/de not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
EP0278316A2 (de) | 1988-08-17 |
EP0278316A3 (en) | 1990-09-26 |
JPS63201860A (ja) | 1988-08-19 |
EP0278316B1 (de) | 1994-12-07 |
DE3852324D1 (de) | 1995-01-19 |
JPH0525333B2 (de) | 1993-04-12 |
US5133053A (en) | 1992-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3852324T2 (de) | Verfahren und System zur Netzwerkverwaltung. | |
DE68919976T2 (de) | Verfahren zur Herstellung von aktuellen Terminaladressen für Systemanwender die verteilte Anwendungsprogramme in einer SNA LU 6.2-Netzwerkumbegung verarbeiten. | |
DE68919631T2 (de) | Verfahren zur Verarbeitung von Programmteilen eines verteilten Anwendungsprogramms durch einen Hauptrechner und einen intelligenten Arbeitsplatz in einer SNA LU 6.2-Netzwerkumgebung. | |
DE69129479T2 (de) | Verteiltes Rechnersystem | |
DE69228621T2 (de) | Objektorientiertes verteiltes Rechnersystem | |
DE68919975T2 (de) | Verfahren für die simultane Ablaufverwaltung eines verteilten Anwenderprogramms in einem Hostrechner und in einer grossen Anzahl von intelligenten Benutzerstationen in einem SNA-Netzwerk. | |
DE60035800T2 (de) | Verfahren zum unterstützen von verteilten transaktionen mit jdbc 1.0 -treibern | |
DE69916928T2 (de) | Zugriffsverfahren und Server für Netzwerkverzeichnis | |
DE69112156T2 (de) | Gerät zur Realisierung von Datenbanken zum Verschaffen von objektorientiertem Aufrufen von Anwendungsprogrammen. | |
DE3789575T2 (de) | Verteiltes Dialogverarbeitungsverfahren in einem komplexen System mit mehreren Arbeitsplätzen und mehreren Gastrechnern und Vorrichtung dafür. | |
DE69131245T2 (de) | Verfahren und Gerät zum Verschaffen von dynamischen Aufrufen von Anwendungsprogrammen in einer verteilten heterogenen Umgebung | |
EP0825524B1 (de) | Verfahren zur Verwaltung der Benennung von Objekten | |
DE69131745T2 (de) | Verfahren und Gerät zum Verschaffen einer Kundenschnittstelle zu einem objektorientierten Aufruf eines Anwendungsprogramms | |
DE69606184T2 (de) | Klient-server-brücke | |
DE69523939T2 (de) | Verfahren zur erzeugung von objektstrukturen für den zugriff auf konventionelle, nicht objekt-orientierte geschäftsanwendungen | |
DE69030340T2 (de) | Makler für die Auswahl von Rechnernetzwerkservern | |
EP1194865B1 (de) | Verfahren zur datenpflege in einem netzwerk teilweise replizierter datenbanksysteme | |
DE3855166T2 (de) | Selbstkonfiguration von Knotenpunkten in einem verteilten, auf Nachrichten gegründeten Betriebssystem | |
DE69423853T2 (de) | Ein-/Ausgabeobjekte in einem Betriebssystemkern | |
DE69328162T2 (de) | Gerät und Verfahren zum Verfügbarstellen eines Teiles eines Namensraumes als ein Teil eines anderen Namensraumes | |
DE69028373T2 (de) | Mehrstufiges Verriegelungssystem und -verfahren | |
DE69637436T2 (de) | Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen | |
DE69220093T2 (de) | Verarbeitungsnetzwerk für verteilte anwendungsprogramme. | |
DE69229453T2 (de) | Verfahren und Anordnung zum Zugriff auf eine relationelle Datenbank, ohne eine objektorientierte Umgebung verlassen zu müssen | |
DE69607360T2 (de) | Unterstützung von anwendungsprogrammen in einer verteilten umgebung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |