DE69628631T2

DE69628631T2 - Dateneingangs/-ausgangsvorrichtung durch Referenzierung zwischen zentralen Verarbeitungseinheiten und Ein-/Ausgabevorrichtungen

Info

Publication number: DE69628631T2
Application number: DE69628631T
Authority: DE
Inventors: Leonard R. Cupertino Fishler; Bahman Sunnyvale Zargham
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1995-12-20
Filing date: 1996-12-19
Publication date: 2004-04-29
Anticipated expiration: 2016-12-20
Also published as: JPH1011372A; EP0790562A2; US5790807A; CA2193174A1; EP0790562B1; EP0790562A3; DE69628631D1

Description

Die vorliegende Erfindung betrifft die Datenübertragung in einem Computersystem. Im besonderen betrifft die Erfindung Verfahren und Vorrichtungen zur Übertragung von Daten zwischen verschiedenen Datenquellen und Datensenken.
Das über Warteschlangen erfolgende, nachrichtbasierte E/A-Verfahren (WEA) in einem System mit gemeinsam benutztem Speicher wird in der am 23. Januar 1995 eingereichten und ebenfalls an den Abtretungsempfänger der vorliegenden Anmeldung abgetretenen U.S.-Anmeldung Nr. 6032267A eingehend beschrieben. Die U.S.-Anmeldung Nr. 6032267 wird weiter unten in groben Zügen zusammengefasst.
1 ist ein Blockdiagramm, das ein fehlertolerantes, paralleles Datenverarbeitungssystem 100 darstellt, welches ein gemeinsam benutztes WEA-Speichersystem 100 beinhaltet. 1 beinhaltet einen Knoten 102 und eine Workstation 104, die über ein lokales Netzwerk (LAN) 105 miteinander in Verbindung stehen. Der Knoten 102 beinhaltet die Prozessoren 106 und 108, die über einen Interprozessorbus (IPB) 109 miteinander verbunden sind. Der IPB 109 ist ein redundanter Bus eines Typs wie er einschlägigen Fachleuten wohlbekannt ist. Bei dem System 100 handelt es sich, was zwar aus 1 nicht hervorgeht, um ein fehlertolerantes, paralleles Computersystem, in welchem zumindest ein Prozessor Daten, welche von anderen Prozessoren im System stammen, mit Sicherungspunkten versieht. Gemäss dem Stand der Technik wird der Speicher in einem solchen System nicht gemeinsam benutzt, um zu vermeiden, dass sich der Speicher als Ursache für Engpasssituationen oder als gemeinsame Fehlerstelle herausstellt. Ein solches fehlertolerantes System wird in seinen Grundzügen zum Beispiel in dem an Katzmann et al. ausgegebenen U.S.-Patent 4.817.091 beschrieben.
Der Prozessor 106 beinhaltet eine CPU 110 und einen Speicher 112 und ist über einen Plattenspeichertreiber 132 und eine Plattenspeichersteuereinheit 114 mit einem Plattenlaufwerk 116 verbunden. Der Speicher 112 beinhaltet ein gemeinsam benutztes Speichersegment 124, welches die WEA-Warteschlangen 125 beinhaltet. Ein Anwendungsprozess 120 und ein Plattenprozess 122 greifen über die WEA-Bibliotheksroutinen 126 auf das gemeinsam benutzte Speichersegment 124 zu. Der Natur von WEA-Einrichtungen folgend, werden Nachrichten, die unter Verwendung des gemeinsam benutzten Speichersegments 124 und der WEA-Bibliothek 126 zwischen dem Anwendungsprozess 120 und dem Plattenprozess 122 übertragen werden, ohne Duplikation der Daten von Prozess zu Prozess gesendet werden.
Der Prozessor 108 beinhaltet auch eine CPU 142 und einen Speicher 144 und ist über einen LAN-Controller 140 mit dem LAN 105 verbunden. Der Speicher 144 beinhaltet ein gemeinsam benutztes Speichersegment 150, welches die WEA-Warteschlangen 151 beinhaltet. Der TCP/IP-Prozess 146 kommuniziert über das gemeinsam benutzte Speichersegment 150 unter Verwendung der WEA-Bibliotheksroutinen 152 mit einem NDS-Verteilerprozess 148 und dem Software LAN-Treiber 158. Auch hier gilt wieder, dass Übertragungen, die das gemeinsam benutzte WEA-Speichersegment 150 verwenden, kein Kopieren der zwischen Prozessen übertragenen Daten beinhalten.
Der TCP/IP-Prozess 146 und das LAN 105 tauschen Daten über den LAN-Treiber 158 und einen LAN-Controller 140 aus.
Der Prozess 120 kommuniziert über den IPB 109 mit dem TCP/IP-Prozess 146, und zwar unter Verwendung der Nachrich tensysteme (NS) 128 und 154 und der Dateisysteme (DS) 130 und 156. Im Gegensatz zu WEA-Übertragungen, ist bei Übertragungen unter Verwendung von Nachrichtensystemen und Dateisystemen eine Duplikation der Daten erforderlich.
1 zeigt somit ein gemeinsam benutztes WEA-Speichersystem zur Datenübertragung zwischen Prozessen, die sich auf einem einzelnen Prozessor befinden. Ein Warteschlangensystem mit gemeinsam benutztem Speicher erhöht die Betriebsgeschwindigkeit der Datenübertragung zwischen auf einem einzelnen Prozessor befindlichen Prozessen und erhöht somit die Gesamtgeschwindigkeit des Systems. Ausserdem macht ein Warteschlangensystem mit gemeinsam benutztem Speicher die Programmierer frei, beim Definieren von Prozessen sowohl vertikale Modularität als auch horizontale Modularität zu implementieren. Diese erhöhte vertikale und horizontale Modularität verbessert die Wartungsfreundlichkeit von Prozessen und erlaubt andererseits weiterhin eine effiziente Übertragung von Daten zwischen Prozessen auf einem einzelnen Prozessor und zwischen Prozessen und Treibern auf einem einzelnen Prozessor.
2 veranschaulicht ein allgemein mit der Bezugszahl 200 bezeichnetes Computersystem. Das Computersystem 200 enthält die Knoten 210, 211, 212 und 213. Die Knoten 210, 211, 212 und 213 sind durch ein Netzwerk 220 untereinander verbunden. Über die Knoten 210, 211, 212 und 213 werden jeweils ein Plattenspeicherprozess 230, ein Anwendungsserverprozess 231, ein Zwischenprotokollprozess 232, sowie ein TCP/IP- und ATM-Treiber 233 betrieben.
Der Anwendungsserverprozess 231 empfängt Datenanforderungen seitens der Benutzer und steuert die Übertragung dieser Daten an den Benutzer über das TNet 220. Die angeforderten Daten befinden sich üblicherweise auf Plattenspeichern, auf welche nur mittels Plattenspeicher-Controller, wie zum Beispiel dem Plattenspeicher-Controller 240 zugegriffen werden kann. Der Zugriff auf die auf einem Plattenspeicher-Controller befindlichen Daten wird nämlich durch einen bestimmten Plattenspeicherprozess vermittelt. Im vorliegenden Fall vermittelt der auf dem Knoten 210 befindliche Plattenspeicherprozess 230 den Zugriff auf den Plattenspeicher-Controller 240. Der Plattenspeicherprozess 230 ist für die Übertragung von Daten zu dem mit dem Plattenspeicher-Controller 240 verbundenen Plattenspeicher und von diesem weggehend verantwortlich.
In Bezug auf das in 2 dargestellte System 200 sei angenommen, dass eine Multimedia-Anwendung eine grosse Menge von Daten 260, angenommen einen MPEG-Videoclip von einem Daten-Plattenspeicher beschaffen muss. Angenommen die Anwendung braucht keines der einzelnen Bytes dieses MPEG-Videoclips zu prüfen oder zu verändern (bzw. zumindest ein Grossteil davon braucht nicht geprüft oder verändert zu werden). Die Anwendung sucht diese Daten 260, weil ein Endnutzer irgendwo im Netz diesen Videoclip angefordert hat. Eine Benutzeroberfläche und der Anwendungsserverprozess 231 kommunizieren mittels eines auf dem TCP/IP implementierten Zwischenprotokolls untereinander. (Bei der Benutzeroberfläche kann es sich um einen Anwendungsprozess oder um eine Hardwareeinrichtung mit minimaler Software handeln. Wie dem auch sei, die Benutzeroberfläche ist hier nicht dargestellt.) Demgemäss müssen die Informationen 262 des Zwischenprotokolls zu den Nachrichten von dem Anwendungsserverprozess 231 hinzugefügt werden und der Zwischenprotokollprozess 232 ist dafür verantwortlich, jene Header-In formationen 262 anzufügen, die gemäss dem Zwischenprotokoll vorgeschrieben sind. Ebenso muss dann die TCP/IP-Protokollinformation 263 auf die abgehende Nachricht geschichtet werden, und der TCP/IP-Treiberprozess 233 im Knoten 213 stellt entsprechende TCP/IP-Header 263 bereit, wie sie gemäss TCP/IP-Protokoll erforderlich sind. Um daher die Daten 260 bei Bedarf von dem verbundenen Plattenspeicher zu dem Plattenspeicher-Controller 240 zu übertragen, verwendet der Anwendungsserverprozess 231 den Plattenspeicherprozess 230, um die Daten 260 von dem Plattenspeicher abzurufen, und verwendet daraufhin das Zwischenprotokoll und die TCP/IP- und ATM-Treiberprozesse 231, 233, um die Daten 260 an die Benutzerschnittstelle weiterzuleiten.
Es sei weiterhin angenommen, dass der Anwendungsprozess 231 als eine seiner Funktionen gewisse anwendungsspezifische Daten 261 am Anfang der abgehenden Daten 260 anhängt.
Sobald der Anwendungsserverprozess 231 erkennt, dass der Plattenspeicherprozess 230 zum Zweck der Verwendung durch den anfragenden Benutzer den Zugriff auf die Daten 260 vermittelt, überträgt der Anwendungsserverprozess 231 eine Nachricht über das TNet 220 an den Plattenspeicherprozess 230, um den Abruf der betreffenden Daten 260 zu veranlassen.
Der Plattenspeicherprozess 230 erstellt eine Befehlssequenz, die beim Empfang durch den Plattenspeicher-Controller 240 von diesem als Befehle zur Wiederauffindung der betreffenden Daten interpretiert werden. Der Plattenspeicherprozess 230 weist den Plattenspeicher-Controller 240 an, die Daten 260 in den Speicher 250 des Unterverarbeitungssystems 210 zu übertragen. Der Plattenspeicher-Con troller 240 informiert den Plattenspeicherprozess 230 über die erfolgreiche Durchführung der geleiteten Datenübertragung.
Der Plattenspeicherprozess 230 meldet seinerseits an den Anwendungsserverprozess 231, dass die Datenübertragung erfolgreich abgeschlossen wurde und fügt seiner Antwort eine Kopie der Daten 260 hinzu. Somit werden die angeforderten Daten 260 in den Anwendungsserverknoten 211 kopiert. Wie für den einschlägig gebildeten Fachmann leicht erkenntlich, können mehrere Kopien erforderlich sein, um die Daten 260 von den (zeichnerisch nicht dargestellten) TNet-Treiber-Pufferspeichern des Anwendungsserverknotens 211 in den Speicherbereich des Anwendungsserverprozesses 231 zu übertragen. Eine zusätzliche Kopie ist typischerweise erforderlich, um die anwendungsspezifischen Daten 261 mit den Plattenspeicherdaten 260 zu einer zusammenhängenden Zeichenfolge zu gestalten. Das weiter oben erwähnte WEA-System kann zwar dafür sorgen, dass sich eine Anzahl dieser prozessorinternen Kopien erübrigt, es kann jedoch nichts dazu beitragen, um zwischen Prozessoren auszutauschende Kopien zu vermeiden.
Die kombinierten Daten 261, 260 wandern nämlich mittels einer weiteren Interprozessor-Kopie von dem Knoten 211 zu dem Knoten 212. Der Knoten 212 fügt seine Zwischenprotokoll-Headerdaten 262 hinzu, und zwar wahrscheinlich durch Kopieren der Daten 262, 261 und 260 in dem einzelnen Pufferspeicher innerhalb des Speichers des Zwischenprotokollprozesses 232.
Auch hier wandern die kombinierten Daten 262, 261, 260 wieder mittels einer weiteren Interprozessor-Kopie von dem Knoten 212 zu dem Knoten 213. Der TCP/IP-Prozess 233 ist bestrebt, die kombinierten Daten 262, 261, 260 in TCP/IP-Paketgrösse zu zerteilen und jeweils an geeigneter Stelle die TCP/IP-Header 263a, 263b, ...., 263n einzufügen. Demgemäss kopiert der TCP/IP-Prozess 233 alle oder zumindest im wesentlichen alle der kombinierten Daten 262, 261, 260 und der TCP/IP-Headerdaten 263a, 263b, .... 263n, um die Daten zu zerteilen und in der korrekten Reihenfolge in dem Speicher 253 wieder zusammenzusetzen. Der TCP/IP-Protokollprozess 233 überträgt daraufhin diese Pakete an den ATM-Controller 270, der sie auf den Weg durch die Netzleitung schickt.
(Für einen Systemdesigner kann es wünschenswert sein, die Verarbeitung von Schichtprotokollen in voneinander getrennte Unterverarbeitungssysteme aufzuteilen, um eine parallele Verarbeitung und somit einen höheren Datendurchsatz des Systems 200 zu ermöglichen.) Solche Unterverarbeitungssysteme verfügen bei Systemen dieses Typs über keinen gemeinsam benutzten Speicher, um eine grössere Fehlertoleranz zu erzielen und um Speicherengpässe zu vermeiden.
Ein nach dieser Technik arbeitendes Computersystem macht es erforderlich, dass die Plattenspeicherdaten 260 fünf mal zwischen den einzelnen Unterverarbeitungssystemen kopiert werden -- und typischerweise zusätzlich dazu noch zwei bis vier Mal innerhalb eines jeden Unterverarbeitungssystems, das nicht nach dem weiter oben erklärten WEA-Prinzip funktioniert. Das Computersystem 200 verbraucht Speicher-Bandbreite in einem Ausmass von (mindestens) dem Fünffachen eines Systems, in welchem ein Kopieren zwischen Prozessoren nicht erfolgte. Das Kopieren führt potentiell zu Engpässen beim Betrieb des Systems 200, weil es E/A- Bandbreite und Speicher-Bandbreite verschwendet und weil es zu Cachespeicherfehlgriffen in der Ziel-CPU führt, wobei all diese Faktoren sich leistungsmindernd auswirken.
Demgemäss besteht Bedarf nach einem System, bei welchem das Kopieren von Daten zwischen Prozessoren vermieden wird, und bei dem gleichzeitig auch Engpässe aufgrund von gemeinsam genutztem Speicher sowie Probleme mit der Fehlertoleranz vermieden werden.
Demgemäss besteht ein Ziel der vorliegenden Erfindung in einem Computersystem, welches unnötiges Kopieren von Daten sowohl innerhalb eines Prozessors als auch zwischen Prozessoren vermeidet.
Dieses und andere Ziele der Erfindung sind für einschlägige Fachleute anhand der Lektüre des vorangegangenen Hintergrunds sowie der nachfolgenden Beschreibung leicht ersichtlich.
Die vorliegende Erfindung schafft ein Verfahren zur Transformation eines Datenstroms gemäss Anspruch 1.
1 ist ein Blockdiagramm, das ein fehlertolerantes, paralleles Datenverarbeitungssystem darstellt, welches ein gemeinsam benutztes WEA-Speichersystem beinhaltet;
2 veranschaulicht ein modulares, durch ein Netzwerk zusammengeschaltetes Multiprozessorsystem;
3A veranschaulicht ein fehlertolerantes Multiprozessorsystem;
3B veranschaulicht eine alternative Konfiguration des Systems aus 3A;
4 veranschaulicht die Schnittstelleneinheit, welche Teil der CPUs aus 3A ist, um den Prozessor und den Speicher an das Netzwerk anzuschliessen;
5 veranschaulicht eine ausführlicher ausgebildete Version des Computersystems 100 aus 3A;
6 ist eine Darstellung einer globalen WEA-Warteschlange;
7 zeigt ein Format einer Nachricht;
8 zeigt ein Format eines Pufferspeicherdeskriptors.
Überblick:
3A veranschaulicht ein Datenverarbeitungssystem 10, welches gemäss den Ausführungen der am 7. Juni 1995 eingereichten und ebenfalls an den Abtretungsempfänger der vorliegenden Erfindung abgetretenen U.S.-Patentanmeldung 5751932 (Anwaltregisternr. 010577-028210) aufgebaut ist. Wie 3A zeigt, umfasst das Datenverarbeitungssystem 10 zwei Unterverarbeitungssysteme 10A und 10B, von denen ein jedes dem Aufbau und der Funktion nach im wesentlichen identisch mit dem anderen ist. Jedes der Subprozessorsysteme 10 beinhaltet eine zentrale Verarbeitungseinheit (CPU) 12, einen Router 14 und eine Mehrzahl von Eingabe-Ausgabe(E/A)-Paketschnittstellen 16. Eine jede der E/A-Paketschnittstellen 16 ist ihrerseits an eine Anzahl (n) von E/A-Geräten 17 und an einen Instandhaltungsprozessor (IP) 18 angeschlossen.
Die CPU 12, der Router 14 und die E/A-Paketschnittstellen 16 sind mittels Trusted Network (TNet)-Links L untereinander verbunden. Wie 3A weiterhin veranschaulicht, verbinden die TNet-Links L auch die Unterverarbeitungssysteme 10A und 10B untereinander, wodurch sowohl der Zugriff eines jeden Unterverarbeitungssystems 10 auf die E/A-Geräte des jeweils anderen als auch als auch eine Kommunikation zwischen den CPUs gewährleistet wird. Einer jeden CPU 12 des Verarbeitungssystems 10 kann Zugriff auf den Speicher jeder anderen CPU 12 gewährt werden, wenngleich auch dieser Zugriff einer Validierung bedarf.
Vorzugsweise sind die Unterverarbeitungseinheiten 10A/10B gepaart, wie in 3A (sowie in der weiter unten besprochenen 3B) veranschaulicht.
Der Informationsaustausch zwischen einem beliebigen Element des Verarbeitungssystems 10 und einem beliebigen anderen Element (z. B. der CPU 12A eines Unterverarbeitungssystems 10A) des Systems und einem beliebigen anderen Element des Systems (z. B. einem E/A-Gerät, das einer E/A-Paket-Schnittstelle 16B des Unterverarbeitungssystems 10B zugeordnet ist), erfolgt über Nachrichten-"Pakete". Jedes Paket besteht aus Symbolen, welche Daten oder einen Befehl enthalten können.
Jeder Router 14 ist mit TNet-Ports ausgestattet, von denen ein jeder im wesentlichen einen identischen Aufbau aufweist (ausgenommen von bestimmten Punkten, die jedoch für die vorliegende Erfindung unerheblich sind). In 3B wird zum Beispiel ein Port eines jeden der Router 14A und 14B dazu verwendet, die entsprechenden Unterverarbeitungssysteme 10A und 10B mit zusätzlichen Unterverarbeitungssystemen 10A' und 10B' zu verbinden und somit ein Verarbeitungssystem 10 zu bilden, welches einen Cluster aus Unterverarbeitungssystemen 10 umfasst.
Bedingt durch den Entwurf der Router 14, durch das zur Leitung von Nachrichtenpaketen benutzte Verfahren und durch eine wohlüberlegte Verwendung der Router 14 bei der Konfiguration der Topologie des Systems 10, kann jede CPU 12 des Verarbeitungssystems 10 aus 3A auf jede beliebige andere "Endeinheit" (z. B. eine CPU oder ein E/A-Gerät) eines jeden der anderen Unterverarbeitungssysteme zugreifen. Zum Beispiel kann die CPU 12B des Unterverarbeitungssystems 10B auf das E/A 16'' des Unterverarbeitungssystems 10A'' zugreifen; oder die CPU 12A' des Unterverarbeitungssystems 10A' kann auf den in der CPU 12B des Unterverarbeitungssystems 12B enthaltenen Speicher zugreifen, um Daten auszulesen oder zu schreiben. Diese letztere Aktivität erfordert, dass die CPU 12A (Unterverarbeitungseinheit 10A') berechtigt ist, den gewünschten Zugriff auszuführen. In dieser Hinsicht verwaltet jede CPU 12 eine Tabelle, welche Einträge für alle Elemente enthält, die berechtigt sind, auf den Speicher dieser CPU zuzugreifen und aus der auch hervorgeht, welche Art des Zugriffs erlaubt ist.
Daten und Befehle werden zwischen den verschiedenen CPUs 12 und den E/A-Paket-Schnittstellen 16 als Pakete ausgetauscht, welche Daten- und Befehlssymbole umfassen. Eine CPU 12 hat keine Möglichkeit, direkt mit einer externen Einrichtung (z. B. mit einer anderen CPU 12 oder über die E/A-Paket-Schnittstelle 16 mit einem E/A-Gerät) zu kommunizieren. Vielmehr erstellt die CPU 12 eine Datenstruktur in dem Speicher 28 und übergibt die Steuerung hierauf an die Schnittstelleneinheit 24 (siehe 4), die eine Blockübertragungsmaschine (BÜM) enthält, welche entsprechend konfiguriert ist, um eine Art von direkter Speicherzugriffsfähigkeit (DMA) bereitzustellen, die es erlaubt, auf die Datenstruktur(en) aus dem Speicher zuzugreifen und diese Datenstrukturen) an einen geeigneten Bestimmungsort zu übertragen.
Der Entwurf des Verarbeitungssystems 10 ermöglicht es, dass ein Speicher 28 einer CPU von externen Quellen aus (z. B. der CPU 12B oder einem E/A-Gerät) gelesen bzw. beschrieben werden kann. Aus diesem Grund muss darauf geachtet werden, sicherzustellen, dass eine von aussen erfolgende Benutzung eines Speichers 28 einer CPU 12 nur in Verbindung mit einer entsprechenden Berechtigung erfolgt.
Szenario: Film auf Abruf
5 veranschaulicht eine ausführlicher ausgebildete Version des Computersystems 100 aus 3A. 5 zeigt ein Computersystem 500, welches die Unterverarbeitungssysteme 510, 511, 512 und 513 enthält. In der vereinfachten, schematischen Darstellung in 5 kann jedes dieser Unterverarbeitungssysteme 510, 511, 512 und 513, wie bereits erörtert, wiederum gepaarte Unterverarbeitungssysteme beinhalten. Obwohl in 5 nicht dargestellt, beinhaltet ein jedes Unterverarbeitungssystem 510, 511, 512 und 513 wie weiter oben beschrieben, jeweils einen Router 14 und eine Schnittstelleneinheit 24. 5 stellt die TNet-Links L dar, welche die Unterverarbeitungssysteme 510, 511, 512 und 513 untereinander verbinden und von einem TNet-Netzwerk 520 kommend als Links L bezeichnet werden.
Über die Unterverarbeitungssysteme 510, 512, 212 und 213 werden jeweils ein Plattenspeicherprozess 530, ein Anwendungsserverprozess 531, ein Zwischenprotokollprozess 532, sowie ein TCP/IP- und ATM-Treiber 533 betrieben. Auch hier haben, wie weiter oben besprochen, in einem typischen System einige der Prozesse 530, 531, 532 und 533 einen Da tensicherungsprozess in einem gepaarten Unterverarbeitungssystem laufen. In der vereinfachten Darstellung in 5 werden diese gepaarten Prozesse durch ihre jeweiligen Primärprozesse dargestellt. Bei dem hier in allgemeinen Zügen beschriebenen "Film auf Abruf"-Beispielszenario empfängt der Anwendungsserverprozess 531 Datenanforderungen eines Benutzers (z. B. Clips oder Filme) und lenkt die Übertragung dieser Daten über das TNet an den Benutzer. Die angeforderten Daten befinden sich üblicherweise auf Plattenspeichern, auf welche nur mittels Plattenspeicher-Controller, wie zum Beispiel dem Plattenspeicher-Controller 540 zugegriffen werden kann. Der Zugriff auf die auf einem Plattenspeicher-Controller befindlichen Daten wird nämlich durch einen bestimmten Plattenspeicherprozess vermittelt. Im vorliegenden Fall vermittelt der auf dem Unterverarbeitungssystem 510 befindliche Plattenspeicherprozess 530 den Zugriff auf den Plattenspeicher-Controller 540. Der Plattenspeicherprozess 530 ist für die Übertragung von Daten zu dem mit dem Plattenspeicher-Controller 540 verbundenen Plattenspeicher und von diesem weggehend verantwortlich. (Da es sich bei dem System 500 um ein zur Gänze fehlertolerantes System handelt, existiert zu dem Plattenspeicher-Controller 540 ein Gegenstück, wobei der Plattenspeicher des Plattenspeicher-Controllers 540 typischerweise gespiegelt wird. Auch diesbezüglich werden die Aspekte der Fehlertoleranz des Systems 500 in der vereinfachten Darstellung aus 5 nicht dargestellt.)
Angenommen die Benutzerschnittstelle und der Anwendungsserverprozess 531 kommunizieren über das auf TCP/IP implementierte RPC-Protokoll miteinander. (Bei der Benutzeroberfläche kann es sich um einen Anwendungsprozess oder um eine Hardwareeinrichtung mit minimaler Software handeln.
Wie dem auch sei, die Benutzeroberfläche ist hier nicht dargestellt.) Demgemäss müssen die Informationen 562 des RCP-Protokolls zu den Nachrichten von dem Anwendungsserverprozess 531 hinzugefügt werden und der Zwischenprotokollprozess 532 ist dafür verantwortlich, jene Header-Informationen 562 anzufügen, die gemäss dem Zwischenprotokoll vorgeschrieben sind. Ebenso muss dann die TCP/IP-Protokollinformation 563 auf die abgehende Nachricht geschichtet werden, und der TCP/IP-Treiberprozess 233 im Unterverarbeitungssystem 513 stellt entsprechende TCP/IP-Header 563 bereit, wie sie gemäss TCP/IP-Protokoll erforderlich sind. Um daher Daten bei Bedarf von dem verbundenen Plattenspeicher zu dem Plattenspeicher-Controller 540 zu übertragen, verwendet der Anwendungsserverprozess 531 den Plattenspeicherprozess 530, um die Daten von dem Plattenspeicher abzurufen, und verwendet daraufhin das Zwischenprotokoll und die TCP/IP- und ATM-Treiberprozesse 532, 533, um die Daten an die Benutzerschnittstelle weiterzuleiten.
Es sei weiterhin angenommen, dass der Anwendungsprozess 531 als eine seiner Funktionen gewisse anwendungsspezifische Daten 561 am Anfang der abgehenden Daten 260 anhängt. Bei diesen einführenden Daten kann es sich zum Beispiel um Film-Trailer, um die vertrauten Copyright-Anmerkungen oder um Befehlssequenzen für einen an ein Fernsehgerät angeschlossenen Videorecorder handeln
Sobald der Anwendungsserverprozess 531 erkennt, dass der Plattenspeicherprozess 530 zum Zweck der Verwendung durch den anfragenden Benutzer den Zugriff auf die Daten 560 vermittelt, überträgt der Anwendungsserverprozess 531 eine Nachricht über das TNet 520 an den Plattenspeicher prozess 530, um den Abruf der betreffenden Daten 560 zu veranlassen.
Der Plattenspeicherprozess 530 erstellt eine Befehlssequenz, die beim Empfang durch den Plattenspeicher-Controller 540 von diesem als Befehle zur Wiederauffindung der betreffenden Daten interpretiert werden. Anstatt jedoch den Plattenspeicher-Controller automatisch anzuweisen, die Daten 560 in den Speicher 550 der Unterverarbeitungseinheit 510 oder sogar in den Speicher 551 des Unterverarbeitungssystems des Anwendungsservers zu stellen, weist die Befehlssequenz den Plattenspeicher-Controller 540 an, die Daten 560 von der Speicherplatte an eine Datensenke zu übertragen.
Datensenken und -quellen
Bei einer Datensenke/-quelle ("DSQ") kann es sich um jedes beliebige Gerät oder um jeden Abschnitt eines Geräts handeln, das bzw. der in der Lage ist, Daten zu speichern und auf Abruf weiterzuleiten. Der unmittelbare Vorteil der Beförderung der Daten 560 von der Speicherplatte zu einer DSQ liegt darin, dass die Zugriffszeit auf die DSQ so gut wie immer besser ist als die Zugriffszeit für das Abrufen der Daten von der Speicherplatte.
Für die DSQ steht eine Reihe von Realisationsmöglichkeiten zur Auswahl: der Speicher 554, welcher in dem Plattenspeicher-Controller 450 selbst enthalten sein kann, oder ein beliebiger der Speicher 550, 551, 552 oder 553 der jeweiligen Unterverarbeitungssysteme 510, 511, 512 oder 513. Als Datensenke kann auch der Speicher 555 des ATM-Controllers 570 dienen, vorausgesetzt der ATM-Controller 570 verfügt über einen Speicher.
Eine andere Option besteht in einem neuartigen Typ von DSQ, der im folgenden als "Globalspeicher" bezeichnet wird. Bei dem Globalspeicher handelt es sich um eine DSQ, die allen Datenübertragungsgeräten auf dem TNet zugänglich ist (sofern das betreffende Gerät, wie in der U.S.-Patentanmeldung Nr. 5751932 beschrieben, über die erforderlichen Berechtigungen verfügt). In 5 wird der Globalspeicher in Form des Globalspeichers 580 dargestellt. Der Speicher 580 ist insofern global, als kein Softwareverfahren vorhanden ist, welches den Zugriff auf den Speicher 580 vermittelt, als es keinen Prozessor gibt, dem der Speicher 580 als Primärspeicher zugeordnet ist, und als kein Primärspeicher existiert (wie etwa die dem Plattenspeicher-Controller 540 zugeordnete Speicherplatte), dem der Speicher 580 untergeordnet ist.
Die Wahl der DSQ hängt von der speziellen Anwendung ab. Entwurfsspezifische Weichenstellungen können die Wahl spezifischer Senken, einer Klasse von Senken oder einer anderen Untergruppe von Senken zwingend vorschreiben. Ein Hauptvorteil, der dafür spricht, die Daten 560 eher in den Globalspeicher 580 als in den Speicher 554 des Plattenspeicher-Controllers 540 zu stellen, liegt darin, dass der durch den Globalspeicher 580 bereitgestellte, zusätzliche Speicher bzw. die zusätzliche Speicher-Bandbreite kostengünstiger ist als ein äquivalenter, zusätzlicher Plattenspeicher-Controller. Auch ist der durch den Globalspeicher 580 erzielte, zusätzliche Speicher bzw. die zusätzliche Speicher-Bandbreite eindeutig wirtschaftlicher als ein äquivalentes, zusätzliches, gepaartes Unterverarbeitungssystem ("UVS") wie z. B. das UVS 510. Globalspeicher wie zum Beispiel der Globalspeicher 580 ermöglichen es dem Systemdesigner, die Skalierung der Speicherkapazität und – bandbreite unabhängig von einer Skalierung der Plattenspeicher-Controller und der Subprozessoren vorzunehmen. Sie ermöglichen es dem Systemdesigner auch, die Leistungsbeeinträchtigung des UVS zu vermeiden, zu der es kommt, wenn die Daten in seinen Speicher gestellt werden. Diese Beeinträchtigung ergibt sich aus dem Ungültigsetzen und Entleeren des Speichercaches, welches erfolgt, wenn die Daten in den Speicher des UVS gestellt werden.
Eine Frage stellt sich, wenn der Bestimmungsort der Daten 560 nicht innerhalb des Einflussbereichs der die Daten ursprünglich anfordernden Stelle (hier des Anwendungsserverprozesses 531) oder auch nur der die Daten zuletzt anfordernden Stelle (hier des Plattenspeicherprozesses 530) gelegen ist. Diese Frage lautet: Wer bestimmt den Bestimmungsort der Daten 560?
Hier sind eine ganze Reihe von Möglichkeiten verfügbar. Einer ersten Möglichkeit zufolge entscheidet der Plattenspeicherprozess 530 darüber, welcher der verfügbaren Globalspeicher (z. B. der Globalspeicher 580) in dem System 500 den Bestimmungsort darstellen soll, und sorgt dafür, dass darauf Platz für die Daten 560 vorhanden ist. Einer anderen Möglichkeit zufolge entscheidet der Anwendungsserverprozess 530 darüber, welche die verfügbaren Globalspeicher sind, in die die Daten 560 gestellt werden können, überlässt die tatsächliche Platzzuteilung jedoch dem Plattenspeicherprozess 530. Nach diesem Szenario teilt der Anwendungsserverprozess 531 dem Plattenspeicherprozess 530 die Kennung der gewählten DSQ mit und gibt an, dass noch keine Zuteilung erfolgt ist.
Als letzte Option entscheidet der Anwendungsserverprozess 531 sowohl darüber, welche der verfügbaren Datensenken als Bestimmungsorte gewählt werden und nimmt zugleich auch die entsprechende Zuweisung vor. Es wird dann zur Aufgabe des Applikationsserverprozesses 531, die Zuweisung durchzuführen und die Zuweisungsinformation, wie weiter unten beschrieben, mittels eines globalen Zeigers an den Plattenspeicherprozess 530 zu übergeben. Der Plattenspeicherprozess 530 weiss dann, dass er keinen Bestimmungsort für die angeforderten Daten zu wählen braucht und dass er den vorab zugeteilten Bestimmungsort in seine Plattenspeicherbefehlssequenz integrieren kann.
Aus dem oben gesagten ergibt sich klar, dass ein Globalspeicher wie z. B. der Globalspeicher 580 entweder selbst über genügend Intelligenz verfügen muss, um seinen Speicher zu verwalten, oder von einem Prozess gesteuert werden muss, der seinen. Speicher für ihn verwaltet. Letzteres Szenario ist analog zu jenem, bei dem der Plattenspeicherprozess 530 den Speicher der mit dem Plattenspeicher-Controller 540 verbundenen Speicherplatte verwaltet. Das erstere ist analog zu einem Unterverarbeitungssystem (z. B. dem Unterverarbeitungssystem 510), welches seinen eigenen Speicher (z. B. den Speicher 550) verwaltet und wird bevorzugt.
Ein Vorteil mag darin liegen, dass es einem Anwendungsprozess wie etwa dem Anwendungsserverprozess 531 ermöglicht wird, zu bestimmen, welche DSQ als Globalspeicher benutzt wird. Der Anwendungsprozess verfügt unter Umständen über ein besseres Verständnis darüber, wie gross seine Speicheranforderungen über längere Zeit hinweg sind. Der Anwendungsprozess könnte zum Beispiel bestrebt sein, eine gewisse Untergruppe aus der Gruppe der Globalspeicher zu ver walten und gewisse Daten in ihnen zu halten, und sie so gewissermassen als Datencachespeicher zu verwenden. Der Video-auf-Bestellung-Filmanwendungsserverprozess 531 könnte den in dem System vorhandenen Globalspeicher als einen grossen Cachespeicher behandeln, der sich über eine Anzahl von Hardwareeinrichtungen erstreckt. Es kann nämlich in der Tat ein Überkreuzungspunkt erreicht werden, ab welchem es wirtschaftlicher ist, ein oft verlangtes Video in einem Globalspeicher zu halten als es im Plattenspeicher aufzubewahren.
Dateneingabe/-ausaabe mittels Referenzierung
Beim Empfang der Plattenspeicherbefehlssequenz, welche die Übertragung der Daten 560 auf die Speicherplatte lenkt, überträgt der Plattenspeicher-Controller 540 die Daten 560 von der Speicherplatte an den DSQ-Bestimmungsort, der von dem Anwendungsprozess 531 und dem Plattenspeicherprozess 530 gemeinsam zugewiesen wird. Es sei hier angenommen, dass es sich bei der ausgewählten Datensenke um den Globalspeicher 580 handelt. Der Globalspeicher 580 (bzw. der Plattenspeicher-Controller 540) informiert anschliessend den Plattenspeicherprozess 530, dass die geleitete Datenübertragung erfolgreich abgeschlossen worden ist. Der Plattenspeicherprozess informiert daraufhin seinerseits den Anwendungsserverprozess 531, dass die angeforderten Daten in den Globalspeicher 580 gestellt worden sind. In jenen Fällen, in denen der Plattenspeicherprozess 530 den tatsächlichen Bestimmungsort der Daten 560 zugewiesen hat, teilt der Plattenspeicherprozess 530 mittels eines weiter unten beschriebenen globalen Zeigers auch dem Anwendungsserverprozess 531 die Adresse der Daten 560 auf dem TNet mit.
Mit einem globalen Zeiger auf die Daten 560 weisend und mit seinen eigenen, anwendungsspezifischen Daten 561 im Speicher 551 würde der Anwendungsserverprozess 531 typischerweise die beiden Datenangaben 561, 560 in einen einzelnen Pufferspeicher kopieren und zusammenfassen und diese Daten an den Zwischenprotokollprozess 532 kopieren-weiterleiten. Erfindungsgemäss gibt der Anwendungsserverprozess 531 den auf die Daten 560 verweisenden globalen Zeiger und einen anderen auf dessen anwendungsspezifische Daten 562 verweisenden globalen Zeiger statt dessen jedoch an den Zwischenprotokollprozess ab. Der Anwendungsserverprozess 531 schafft nämlich einen logisch (d. h. virtuell) zusammenhängenden Speicherblock, indem er die physisch nicht zusammenhängenden Datenblöcke 561, 560 miteinander verkettet. (Physisch gesehen sind die Daten 561, 560 nämlich strikt nicht zusammenhängend und befinden sich sogar in physisch getrennten DSQs.) Der Anwendungsserverprozess 531 gibt daraufhin die Zeigerkette an den Zwischenprotokollprozess 532 ab.
Der Zwischenprotokollprozess 532 übergeht seinerseits das Kopieren der Daten 561, 560 in seinen eigenen, zugeordneten Speicher 532. Der Prozess 532 gibt statt dessen die beiden globalen auf die Daten 561, 560 verweisenden Zeiger zusammen mit einem dritten auf die Zwischenprotokollkopfdaten 562 verweisenden globalen Zeiger an den TCP/IP-Prozess 533 weiter. Der Zwischenprotokollprozess 532 vermeidet dadurch das zwischen den Prozessoren über das Netzwerk erfolgende Kopieren, das ansonsten zum Abrufen der Daten 561, 560 erforderlich ist. Der Prozess 532 vermeidet auch das prozessorinterne Kopieren, das ansonsten erforderlich ist, um die Daten von den Netzwerktreiberpufferspeichern in das Betriebssystem des Unterverarbeitungssystem 510 und in den Speicherplatz des Zwischenprotokollprozesses 532 zu kopieren.
Die TCP/IP-Protokollverarbeitung macht zum Zweck der Übertragung das Aufteilen der logisch zusammenhängenden Daten in paketgrössengerechte Datenblöcke erforderlich, wobei am Beginn eines jeden Pakets dessen eigener TCP/IP-Header steht. Der TCP/IP-Prozess 533 verarbeitet die Kette von TNet-Zeigern. Beim Durchgehen der Kette erzeugt er einen TCP/IP-Header 563a für den ersten paketgrössengerechten Datenblock innerhalb der logisch zusammenhängenden Daten 562, 561, 560, einen TCP/IP-Header 563b für den zweiten Datenblock innerhalb der Daten 562, 561, 560, und so weiter bis zum letzten, N-ten TCP/IP-Header 563n für den letzen Datenblock innerhalb der Daten 562, 561, 560.
Da diese TCP/IP-Header in die Daten 562, 561, 560 eingefügt werden müssen, muss der TCP/IP-Prozess 533 die auf die Daten 562, 561, 560 verweisenden, globalen Zeiger in eine Reihe von Zeigern umwandeln, die jeweils auf Daten verweisen, welche nicht grösser sind als ein TCP/IP-Paket. Jeder globale Zeiger beinhaltet die Kennung seiner Ursprungs-DSQ, die Adresse der Daten innerhalb der identifizierten DSQ und die Grösse der an dieser Adresse befindlichen Daten. Die Transformationen der auf 562, 561, 560 verweisenden, globalen Zeiger in eine Reihe von paketgrössengerechten Zeigern werden weiter unten beschrieben. Der TCP/IP-Prozess 533 kann nun die neue Reihe transformierter globaler Zeiger an Pakete der Daten 562, 561, 560 weitergeben, wobei globale Zeiger in die TCP/IP-Header 563a, 563b, ... 563n eingestreut werden.
Angenommen die Zwischenprotokolldaten 562, die anwendungsspezifischen Daten 561 und ein gewisser erster Abschnitt 560' der Plattenspeicherdaten 560 bilden zusammen genommen das erste Paket. Weiterhin sein angenommen, dass ein gewisser zweiter Abschnitt 560'' der Plattenspeicherdaten 560 ein zweites Paket bildet. Ein letzter Abschnitt 560''' der Plattenspeicherdaten 560 bildet schliesslich das letzte zu übertragende Datenpaket. Der TCP/IP-Prozess 533 springt zu dem ATM-Controller 570 weiter, wobei die Kette der globalen Zeiger auf die folgenden Daten verweist: die TCP/IP-Headerdaten 563a, die Zwischenprotokoll-Headerdaten 562, die anwendungsspezifischen Daten 561, die Plattenspeicherdaten 560', die TCP/IP-Headerdaten 563b, die Plattenspeicherdaten 560'', ..., die TCP/IP-Headerdaten 563n und die Plattenspeicherdaten 560'''.
Zu einem Zeitpunkt, welcher von der Programmierung des ATM-Controllers 570 und dem dynamischen Status des Systems 500 abhängig ist, geht der ATM-Controller 570 die Kette der von dem TCP/IP-Prozess 533 erhaltenen globalen Zeiger durch und holt die aktuellen Daten 563a, 562, 561, 560', 563b, 560'', ..., 563n und 560''' in den Speicher 555. Der ATM-Controller holt die TCP/IP-Headerdaten 563a, 563b, ..., 563n aus dem Speicher 553 des TCP/IP-Protokoll-Unterverarbeitungssystems 513; den Zwischenprotokoll-Header 562 aus dem Speicher 552 des Zwischenprotokoll-Unterverarbeitungssystems 512; die anwendungsspezifischen Daten 561 aus dem Speicher 551 des Anwendungsserver-Unterverarbeitungssystem 511; und die Plattenspeicherdaten 560', 560'', ... und 560''' aus dem Globalspeicher 580.
Nachdem der ATM-Controller alle erforderlichen Daten in seinem physischen Speicher abgelegt hat, führt er die Übertragung der Daten durch.
Es sei hier angemerkt, dass die Anwendungsdaten 561, die Zwischenprotokoll-Headerdaten 562 und die TCP/IP-Protokoll-Headerdaten 563 jeweils nur einmal kopiert worden sind. Die Plattenspeicherdaten wurden zweimal kopiert, obwohl das Kopieren der Daten 560 von dem Plattenspeicher-Controller 540 in den Globalspeicher 580 streng genommen keine Notwendigkeit darstellte. Nach dem Stand der Technik wären mit derselben Hardware und demselben Datenstrom des Systems 500 die Anwendungsdaten 561 mindestens dreimal kopiert worden, die Zwischenprotokoll-Headerdaten 562 wären zweimal kopiert worden, und die Plattenspeicherdaten 560 wären sechsmal kopiert worden. In Situationen, in denen die Plattenspeicherdaten umfangreich sind (wie in dem hier beschriebenen "Film auf Abruf"-Umfeld) oder in denen die Anzahl der Zwischenprotokoll-Unterverarbeitungssysteme gross ist, führt die Verringerung des Kopieraufwands zu beträchtlichen Einsparungen. Die Kosten können dadurch nahezu an jene eines Systems mit massiv paralleler Verarbeitung und gemeinsam genutztem Speicher herangeführt werden, ohne jedoch die Probleme in Bezug auf Speicherengpassprobleme aufzuweisen, zu denen es bei einem solchen System gewöhnlich kommt.
Datenstrukturen
Im folgenden werden die Datenstrukturen und -protokolle beschrieben, die in einer bevorzugten Ausführungsform verwendet werden, um die erfindungsgemässe Dateneingabe/-ausgabe mittels Referenzierung zu realisieren.
Als erstes muss ein netzwerkweites Schema zur Erkennung von DSQ-spezifischen Adressen implementiert werden, um es einer Referenz bzw. einem auf Daten in einer Datensenke/-quelle (DSQ) verweisenden Zeiger zu ermöglichen, für einen auf einer Einrichtung befindlichen Prozess Bedeutung zu haben, die nur über ein Netzwerk mit der DSQ verbunden ist. In der hier beschriebenen Dateneingangs/-ausgangsvorrichtung durch Referenzierung werden diese Adressen als globale Adressen bezeichnet.
In einer Ausführungsform handelt es sich bei den globalen Adressen um eine Kombination aus, erstens, einer ID einer Netzwerk-DSQ und, zweitens, eine von dieser DSQ erkannten Adresse. Die ID einer Netzwerk-DSQ ist einzigartig unter allen Einrichtungen, die innerhalb des Netzwerks als DSQ fungieren.
In der Ausführungsform ist die von einer bestimmten DSQ erkannte Adresse dem Adressierschema dieser bestimmten DSQ eigen. Eine DSQ. kann virtuelle oder physikalische, globale Adressen verwalten. Zum Beispiel verwaltet der Plattenspeicher-Controller 540 mit grosser Wahrscheinlichkeit physikalische Adressen in seinem Speicher 554. Ein Unterverarbeitungssystem kann Adressen in virtuellem oder realem Speicher verwalten, je nachdem ob die globalen Adressen in dem virtuellen Speicherplatz eines Prozesses oder in dem realen Adressplatz des globalen WEA-Treibers auf Systemebene zugewiesen werden. Das Halten der globalen Adressen in dem realen Adressplatz des WEA-Treibers vermeidet Hardware- und Softwareübersetzungskosten.
Globale Adressen werden in globale WEA-Datenstrukturen integriert, welche zwischen Netzwerkeinrichtungen ausge tauscht werden. In einer Ausführungsform sind die wichtigsten globalen WEA-Datenstrukturen eine Warteschlange, eine Nachricht, ein Nachrichtdeskriptor und ein Pufferspeicherdeskriptor.
6 veranschaulicht eine globale WEA-Warteschlange 600 gemäss einer Ausführungsform der Erfindung. Eine Warteschlange 600 existiert in dem Speicher einer jeden DSQ in dem Netzwerk. Eine Warteschlange 600 beinhaltet einen Typ 601, einen benutzerlesbaren Warteschlangennamen 602, einen 'Erste Nachricht'-Zeiger 604, einen 'Letzte Nachricht'-Zeiger 606, einen Nachrichtenzählstand 608, Warteschlangenattribute 610, eine Erzeugerprozess-ID 612, einen auf eine benutzerdefinierte GET()-Funktion (HOLEN()-Funktion) verweisenden Zeiger 614, einen auf eine benutzerdefinierte PUT()-Funktion (ABLEGEN()-Funktion) verweisenden Zeiger 616, und einen auf einen benutzerdefinierten Steuerblock verweisenden Zeiger 618.
Der Deskriptortyp 601 gibt an, dass es sich bei dieser Datenstruktur um eine Warteschlange handelt. Bei dem Warteschlangennamen 602 handelt es sich um einen Namen der Warteschlange, z. B. "GLOBALE WEA ANKOMMEND". Der 'Erste Nachricht'-Zeiger 604 verweist auf einen 'Erste Nachricht'-Deskriptor 622 einer ersten Nachricht in einer Doppelverbundliste von Nachrichten 620, und der 'Letzte Nachricht'-Zeiger 606 verweist auf einen 'Erste Nachricht'-Deskriptor 624 einer letzten Nachricht in der Doppelverkettungsliste 620.
Der Nachrichtzählstand 608 enthält die Anzahl der Nachrichten in der Doppelverkettungsliste 620. Die Warteschlangenattribute 610 beinhalten Attribute der Warteschlange, z. B. ob ein Prozess geweckt werden soll, wenn Daten in seine Eingangswarteschlange gestellt werden, und ob vor, nach bzw. anstelle der globalen WEA-Bibliotheksfunktion GET_MES-SAGE() eine benutzerdefinierte GET()-Funktion aufgerufen werden soll. (Globale WEA-Bibliotheksfunktionen werden weiter unten beschreiben.) Bei der Erzeugerprozess-ID 612 handelt es sich um die ID des Prozesses, der die Warteschlange erzeugt hat. Die globale WEA-Bibliothek kann diesen Prozess jedes mal aufwecken, wenn eine Warteschlange in einen 'Nicht leer'-Zustand versetzt wird.
Der Zeiger 614 verweist auf eine benutzerdefinierte GET()-Funktion, die jedesmal dann ausgeführt wird, wenn ein Prozess die globale WEA-Bibliotheksfunktion GET_MESSAGE() aufruft, um eine Nachricht von der Warteschlange 600 zu holen. Die benutzerdefinierte GET()-Funktion ermöglicht es, dass die benutzerdefinierte Funktion zusätzlich zu, bzw. anstelle einer in der globalen WEA-Bibliothek enthaltenen Standard-GET-Funktion ausgeführt wird. Wenn es sich zum Beispiel bei der Warteschlange 600 um eine Eingangswarteschlange für einen E/A-Treiber handelt, so könnte eine benutzerdefinierte GET()-Funktion eine von dem Treiber auszuführende E/A-Operation auslösen. Der Treiber kann sich auch eine Anzahl von aussergewöhnlichen E/A-Operationen merken und diese Anzahl jedesmal anpassen, wenn eine GET-Funktion ausgeführt wird. Als weiteres Beispiel kann eine GET()-Funktion bewirken, dass von dem Prozess, der die Warteschlange erzeugt hat, eine interne Verwaltungsroutine ausgeführt wird.
Der Zeiger 616 verweist auf eine benutzerdefinierte PUT()-Funktion, die in parallel zu dem Zeiger 614 laufender Weise verarbeitet wird. So kann etwa in einer einem LAN- Treiber zugeordneten Warteschlange die PUT()-Funktion eine Transportschichtroutine dazu veranlassen, Informationen an das TNet 520 auszugeben.
Der Zeiger 618 verweist auf einen benutzerdefinierten Steuerblock. Dieser Steuerblock wird typischerweise von einem oder von beiden der benutzerdefinierten PUT()- und GET()-Funktionen benötigt. Zum Beispiel könnte der Steuerblock für einen Treiber bestimmt sein, der Informationen ausgibt, wenn die Informationen an das Warteschlangensystem gesendet werden.
7 zeigt ein Format einer Nachricht 700, die in der Doppelverbundliste 620 aus 6 gespeichert ist. Eine Nachricht besteht aus verbundenen Nachrichtdeskriptoren und ist in die Liste 620 aus 6 hinein verknüpft. 7 zeigt die Nachrichtdeskriptoren 622 und 622', welche in einer Verbundliste durch den Zeiger 714 zu einer Nachricht verbunden werden. Ein Nachrichtdeskriptor beinhaltet einen Deskriptortyp 704, einen 'Nächste Nachricht'-Zeiger 710, einen 'Vorausgehende Nachricht'-Zeiger 712, einen 'Fortsetzende Nachricht'-Nachrichtdeskriptorzeiger 714, einen Pufferspeicherdeskriptorzeiger 716, einen Benutzerdaten-Lesezeiger 718, einen Benutzerdaten-Schreibzeiger 720, und einen Rückgabe-Warteschlangenzeiger 722. Ein Nachrichtdeskriptor beinhaltet auch die Längen 719, 721, welche jeweils den Zeigern 718, 720 zugeordnet sind.
In 7 bilden die Nachrichtdeskriptoren 622 und 622' zusammen eine einzelne Nachricht. Der Deskriptortyp 704 gibt an, dass es sich bei dieser Datenstruktur um einen Nachrichtdeskriptor handelt. Der 'Nächste Nachricht'-Zeiger 710 verweist auf den 'Erste Nachricht'-Deskriptor 624 einer in der Doppelverbundliste 620 gespeicherten, nächsten Nachricht. Der 'Vorausgehende Nachricht'-Zeiger 712 verweist auf den 'Erste Nachricht'-Deskriptor einer in der Doppelverbundliste 620 gespeicherten, vorausgehenden Nachricht. Der 'Fortsetzende Nachricht'-Nachrichtdeskriptorzeiger 714 verweist auf den 'Nächste Nachricht'-Deskriptor 622 innerhalb der aktuellen Nachricht 622. Multiple Nachrichtdeskriptoren sind notwendig, um verstreute Daten darzustellen, und eine einzelne Nachricht kann multiple Nachrichtdeskriptoren beinhalten, welche auf an verschiedenen Speicherorten befindliche Daten verweist. Der Pufferspeicherdeskriptorzeiger 716 verweist auf einen Pufferspeicherdeskriptor 730. Der Pufferspeicherdeskriptor 730 verweist auf einen Daten-Pufferspeicher 740.
Ein Benutzerdatenlesezeiger 718 ist ein Zeiger in den Pufferspeicher 740 und zeigt an, an welchem Punkt innerhalb des Datenpuffers 740 die Leseoperation beginnen soll (bzw. beendet worden ist). Ein Benutzerdatenschreibzeiger 720 ist ein Zeiger in den Pufferspeicher 740, der anzeigt, an welchem Punkt innerhalb des Datenpuffers 740 die Leseoperation beginnen soll (bzw. beendet worden ist). Die Längen 719, 721 geben jeweils die maximale Datenmenge an, die aus dem Lesezeiger 718 ausgelesen bzw. in den Schreibzeiger 720 geschrieben werden können.
Ein Rückgabe-Warteschlangenzeiger 722 verweist auf eine Rückgabe-Warteschlange (nicht gezeigt). Wenn ein Nachrichtdeskriptor über die globalen WEA-Bibliotheksroutinen zurückgegeben wird, (d. h. wenn die Verarbeitung der Nachricht abgeschlossen ist), wird der zurückgegebene Nachrichtdeskriptor in die Rückgabe-Warteschlange gestellt, sofern die Rückgabe-Warteschlange spezifiziert ist. So kann es zum Beispiel nötig sein, dass ein Prozess die gesendeten Nachrichten zählt. Anstatt den Nachrichtdeskriptor 622 nach dessen Entnahme aus der Warteschlange 600 in einen freien Speicherpool zu stellen, wird der Nachrichtdeskriptor 622 zur weiteren Verarbeitung durch einen Prozess in die Rückgabe-Warteschlange gestellt. Andere Nachrichtdeskriptoren 622' in einer Nachricht 700 können verschiedene sekundäre Rückgabe-Warteschlangenzeiger 722' oder NULL Rückgabe-Warteschlangenzeiger haben. Diese sekundären Rückgabe-Warteschlangenzeiger werden durch die der vorliegenden Anwendung entsprechenden Prozesse verarbeitet. Die Rückgabe-Warteschlange für einen Nachrichtdeskriptor befindet sich gewöhnlich in jener DSQ, die den Nachrichtdeskriptor ursprünglich für seine aktuelle Verwendung zugewiesen hat.
8 zeigt ein Format eines Pufferspeicherdeskriptors 730 gemäss einer Ausführungsform der Erfindung. Der Pufferspeicherdeskriptor 730 ist Bestandteil der Nachricht 722 aus 7. Ein Deskriptortyp 802 gibt an, dass es sich bei dieser Datenstruktur um einen Pufferspeicherdeskriptor handelt. Der Pufferspeicherdeskriptor 730 beinhaltet einen Datenpufferbasiszeiger 808, einen Datenpuffergrenzzeiger 810 und einen Referenzzählstand 812. Der Datenpufferbasiszeiger 808 verweist auf eine Basis eines Datenpuffers 840 im Speicher. Der Datenpuffergrenzzeiger 810 verweist auf das Ende des Datenpuffers 840. Der Referenzzählstand 812 zählt die Anzahl der Pufferspeicherdeskriptorzeiger 716, welche auf einen spezifischen Pufferspeicherdeskriptor 730 verweisen.
Eine Warteschlange 600 befindet sich lokal auf der DSQ, auf welcher sie erzeugt wird. Die Datenstruktur einer Warteschlange 600 wird niemals an eine andere DSQ innerhalb des Netzwerks übertragen. Demgemäss handelt es sich bei den Zeigern 604, 606, 612, 614, 616 und 618 um lokale Adressen und nicht um globale Adressen.
Die Nachrichtdeskriptoren 622 werden jedoch sehr wohl zwischen den über das Netzwerk verbundenen DSQs übertragen. Daher sind die Pufferspeicherdeskriptorzeiger 716 und die Benutzerdatenlese- und -schreibzeiger 718, 720 globale Zeiger, die von der DSQ interpretiert werden, welche sie generiert hat.
Personen mit einschlägigen Fachkenntnissen werden erkennen, dass gewisse Felder eines Nachrichtdeskriptors 622 weggelassen werden können, wenn der Nachrichtdeskriptor 622 zwischen netzwerkverbundenen Einrichtungen ausgetauscht wird. Solche Felder beinhalten zum Beispiel die 'Nächste Nachricht'- und 'Vorausgehende Nachricht'-Zeiger 710, 712; und den 'Fortgesetzte Nachricht'-Nachrichtdeskriptorzeiger 714. Die globale WEA-Bibliothek an der empfangenden Netzwerkeinrichtung kann diese Felder anlässlich der Zuweisung von Nachrichtdeskriptoren, die Nachricht in eine Warteschlange zu stellen, generieren. Ein Nachrichtdeskriptor ohne diese Felder wird als globale Form eines Nachrichtdeskriptors bezeichnet und der Typ 704 kann geändert werden, um die Auslassungen widerzuspiegeln.
Umgekehrt sind der Pufferspeicherdeskriptorzeiger 716, die Benutzerdatenlese- und -schreibzeiger 718, 720, die entsprechenden Längenfelder 719, 721, der Rückgabe-Warteschlangenzeiger 722 und die Prüfsumme in der globalen Form eines Nachrichtdeskriptors 622, wie er zwischen DSQs übertragen wird, enthalten.
Der Pufferspeicherdeskriptor 730 wird nicht über das Netzwerk hinweg übertragen. Der Datenpufferspeicherbasiszeiger 808 ist für Lese- oder Schreiboperationen in dem Datenpufferspeicher 740 irrelevant. Lese- und Schreibzeiger werden in den Benutzerdatenlese- und -schreibzeigern 718, 720 eines Nachrichtdeskriptors 622 bereitgestellt. In ähnlicher Weise ist der Datenpufferspeichergrenzzeiger 812 für das Lesen und Beschreiben des Pufferspeichers über das Netzwerk hinweg irrrelevant. Gemäss den weiter unten beschriebenen Protokollen erfordert ein gut funktionierender Lese- und Schreibprozess einen Datenpufferspeicher 740 von spezifizierter Länge, und der gut funktionierende Zuweisungsprozess dieses Datenpufferspeichers 740 gewährleistet, dass die Benutzerdatenlese- bzw. -schreibzeiger 718 bzw. 720 auf ein Segment des Datenpufferspeichers 740 verweist, welches zumindest die spezifizierte Länge umfasst. (In jenen Fällen, in denen die spezifizierte Länge über eine Kette von Nachrichtdeskriptoren verteilt. ist, gewährleistet der gut funktionierende Zuteilungsprozess, dass die Kette der Benutzerdatenzeiger auf Segmente der Datenpufferspeicher 740 verweisen, welche zusammen genommen zumindest die spezifizierte Länge ausmachen.)
Protokolle
– Nachrichtbasierte Kommunikationsformen
Die Kommunikation zwischen zwei beliebigen Komponenten des Systems 500 (z. B. zwischen einem ersten und einem zweiten Unterverarbeitungssystem, oder zwischen einem UVS und einem Globalspeicher) durch die Bildung und Übertragung von Nachrichten niedriger Ebene implementiert wird, die in den Paketen beinhaltet sind. (Nachrichten niedriger Ebene un terscheiden sich von den Nachrichten des hier beschriebenen globalen WEA-Systems.) Diese Pakete werden von der übertragenden Komponente oder Quellkomponente über die systemweite Bereichsnetzwerkstruktur, das TNet 520, zu einer Zielkomponente übertragen.
Die Einzelheiten betreffend die Art und Weise, in der die Systemkomponenten, die Router 14 und die Schnittstelleneinheiten 24 (einschliesslich der BÜM-/DMA- Einrichtungen) miteinander kooperieren, um diese Kommunikation zu ermöglichen, werden in der U.S.-Patentanmeldung Nr. 08/485.217 eingehend erklärt. Im Rahmen der vorliegenden Offenlegungsschrift genügt es, zu wissen, dass ein HAC-Paket verwendet wird, um Anforderungen zu lesen, und dass ein HADC-Paket verwendet wird, um Schreibdaten zu übertragen.
– GLOBALE WEA
Die globale WEA-Bibliothek beinhaltet die folgenden Software-Eintrittsstellen, von denen eine jede weiter unten beschrieben wird:

– eine globale WEA-Warteschlange erzeugen;
– eine globale WEA-Warteschlange löschen;
– einen Nachrichtdeskriptor holen;
– einen Nachrichtdeskriptor kopieren;
– eine Nachricht zurückgeben;
– eine Nachricht kopieren;
– eine Nachricht von einer globalen WEA-Warteschlange holen;
– eine Nachricht in eine globale WEA-Warteschlange stellen;

Ein Prozess ruft eine CREATE_QUEUE()-Prozedur auf, um eine benannte Warteschlange bei der globalen WEA-Bibliothek zu registrieren, wodurch eine Eingangs- und eine Ausgangswarteschlange erzeugt wird. Demgemäss überträgt ein aufrufender Prozess den Namen eines Ports, und die CREATE_QUEUE()-Routine gibt die Warteschlangen-IDs der Eingangs- und der Ausgangswarteschlange für den Port, sowie die Modul-ID zurück. Nachdem der Prozess die CREATE_QUEUE()-Routine erfolgreich aufgerufen hat, kann der Prozess in der Folge die PUT_MESSAGE()-Routine und die GET_MESSAGE()-Routine aufrufen, welche weiter unten beschrieben werden.
Dem entsprechend kann ein Prozess die globale WEA-Bibliotheksroutine DELETE_QUEUE() aufrufen. Diese Funktion entfernt eine Registrierung aus der globalen WEA-Bibliothek. Ein Prozess überträgt die Warteschlangen-IDs der Eingangs- und der Ausgangswarteschlange, deren Registrierung zu entfernen ist. Nach der Entfernung der Registrierung ist ein Prozess nicht mehr in der Lage, über die jeweils identifizierten Warteschlangen abgehende Nachrichten zu senden bzw. eingehende Nachrichten zu empfangen.
Die PUT_MESSAGE()-Routine stellt eine spezifizierte Nachricht in eine spezifizierte Warteschlange. In jenen Fällen, in denen die Nachricht und die Warteschlange sich nicht in derselben DSQ befinden, wird das Nachrichtenpaketsystem der niedrigen Ebene aufgerufen, um eine globale Form der spezifizierten Nachricht von der Nachricht-DSQ zu der Warteschlangen-DSQ zu übertragen. Die Nachricht wird in der Ursprungs-DSQ freigemacht.
Der GET_MESSAGE_DESCRIPTOR()-Eintrittspunkt gibt einen Zeiger auf einen Nachrichtdeskriptor zurück, welcher einen Datenpufferspeicherzeiger auf einen Datenpufferspeicher mit (mindestens) einer spezifizierten Länge enthält. Demgemäss nimmt der GET_MESSAGE_DESCRIPTOR()-Eintrittspunkt eine Modul-ID und eine Datenpufferspeicherlänge als Argumente und gibt einen auf einen Nachrichtdeskriptor verweisenden Zeiger zurück. Eine DSQ bzw. ein Prozess, welche (r) eine GET_MESSAGE_DESCRIPTOR()-Routine aufruft, fordert nämlich von der globalen WEA-Bibliothek an, einen Datenspeicherpuffer der spezifizierten Länge zuzuteilen, einen auf einen bestimmten Punkt innerhalb des soeben zugeteilten Datenpufferspeichers initialisierten Pufferspeicherdeskriptor zuzuteilen, und einen Nachrichtdeskriptor zuzuteilen, welcher entsprechend initialisiert ist, um auf den soeben zugeteilten Pufferspeicherdeskriptor zu verweisen und auf den Schreib-Speicherort innerhalb des Datenpufferspeichers zu verweisen.
(In jenen Fällen, in denen ein aktuell in Verwendung stehender Datenpufferspeicher einen nicht zugeteilten Abschnitt aufweist, der gross genug ist, um für eine nachfolgende GET_MESSAGE_DESCRIPTOR()-Anforderung verwendet werden zu können, kann dieser (nicht zugeteilte Abschnitt des) Datenpufferspeicher(s) für diese möglicherweise nicht zugeordnete GET_MESSAGE_DESCRIPTOR()-Anforderung verwendet werden.)
In einer bevorzugten Ausführungsform werden freie Nachrichtdeskriptoren in einer Liste der freien Nachrichtdeskriptoren gehalten. Die Verwaltung einer solchen Freigabeliste ist nach dem Stand der Technik wohlbekannt.
Die DUPLICATE_MESSAGE_DESCRIPTOR()-Routine gibt eine Kopie des spezifizierten Nachrichtdeskriptors zurück. Demgemäss nimmt die DUPLICATE_MESSAGE_DESCRIPTOR()-Routine eine Modul-ID und einen auf einen Nachrichtdeskriptor verweisenden Zeiger als Argumente und gibt einen auf einen Nachrichtdeskriptor verweisenden Zeiger zurück. Der zurückgegebene Nachrichtdeskriptor verweist auf denselben Pufferspeicherdeskriptor und auf dieselben Daten wie der ursprünglich spezifizierte Nachrichtdeskriptor und der Referenzzählstand dieses Pufferspeicherdeskriptors wird durch den Kopiervorgang um eins erhöht. Der kopierte Nachrichtdeskriptor stammt von der Liste der freien Nachrichtdeskriptoren.
Der Referenzzählstand des zugrundeliegenden Pufferspeicherdeskriptors muss aktualisiert werden. Dieser Aktualisierungsvorgang kann entweder dadurch erfolgen, dass von der DSQ, von welcher der Nachrichtdeskriptor stammt, angefordert wird, den Referenzzählstand zu erhöhen, oder dadurch, dass der Nachrichtdeskriptor in seine Ursprungs-DSQ zurückgestellt wird, und diese DSQ veranlasst wird, den Nachrichtdeskriptor zu kopieren, woraufhin Original und Kopie wieder rückübertragen werden.
Die globale WEA-Bibliothek enthält eine entsprechende RETURN_MESSAGE_DESCRIPTOR()-Routine. Diese Routine verschiebt einen in der aufrufenden DSQ befindlichen Nachrichtdeskriptor in die Freigabeliste der Nachrichtdeskriptoren in der DSQ, welche den Nachrichtdeskriptor ursprünglich für seine aktuelle Verwendung zugewiesen hat. Wenn allerdings der Rückgabe-Warteschlangenzeiger des Nachrichtdeskriptors nicht gleich NULL ist, so gibt die Routine diesen Nachrichtdeskriptor an die angegebene Rückgabe-Warte schlange zurück. Die RETURN_MESSAGE_DESCRIPTOR()-Routine nimmt als Argumente eine Modul-ID und einen auf den rückzugebenden Nachrichtdeskriptor verweisenden Zeiger.
In der Ursprungs-DSQ wird der Referenzzählstand des Pufferspeicherdeskriptors um eins verringert, da nun ein Nachrichtdeskriptor weniger auf diesen Pufferspeicherdeskriptor verweist. Wenn der Referenzzählstand Null erreicht, kehrt der Datenpufferspeicherdeskriptor in den Pool der freien Datenpufferspeicher zurück. (Siehe die weiter unten erfolgende Beschreibung von DATR_BUFFER_RETURN().)
Bei der RETURN_MESSAGE() -Routine handelt es sich um eine rekursive Version der RETURN_MESSAGE_DESCRIPTOR-Routine. Die RETURN_MESSAGE-Routine geht die Kette von Nachrichtdeskriptoren durch, die von dem identifizierten Nachrichtdeskriptor angeführt werden, löst die Verbindung des jeweils führenden Nachrichtdeskriptors mit allfällig daran anschliessenden Nachrichtdeskriptoren (d. h. nullt den 'Fortsetzende Nachricht'-Nachrichtdeskriptorzeiger aus dem führenden Nachrichtdeskriptor heraus) und gibt den führenden Nachrichtdeskriptor an die entsprechende Rückgabe-Warteschlange zurück, wobei der Vorgang so lange wiederholt wird, bis keine weiteren 'Fortsetzende Nachricht'-Nachrichtdeskriptoren mehr vorhanden sind.
Die DUPLICATE_MESSAGE()-Routine kopiert eine gesamte Nachricht. Die DUPLICATE_MESSAGE-Routine nimmt als Argument eine Modul-ID und einen auf den führenden Nachrichtdeskriptor der Nachricht weisenden Zeiger und gibt einen Zeiger zurück, welcher auf den führenden Nachrichtdeskriptor der kopierten Nachrichtstruktur verweist. Die gesamte Nachricht wird kopiert (allerdings nicht die Daten), wobei bei dem führenden Nachrichtdeskriptor der Originalnachricht begonnen wird und im Anschluss daran alle Nachrichtdeskriptoren durchgegangen werden, die über die 'Fortsetzende Nachricht'-Nachrichtdeskriptorzeiger mit dieser verkettet sind. Der Referenzzählstand des Pufferspeicherdeskriptors, auf den von einem jeden der ursprünglichen Nachrichtdeskriptoren aus verwiesen wird, wird um eins erhöht, um dem Kopiervorgang des Nachrichtdeskriptors Rechnung zu tragen.
– NACHRICHTDESKRIPTOROBJEKTE
Ein anderes Protokoll umfasst die Charakterisierung der Nachrichtdeskriptoren. In einer Ausführungsform handelt es sich bei der globalen Form des Nachrichtdeskriptors um ein Objekt im Sinne der objektorientierten Programmierung. Zur Handhabung des Objekts stehen ausschliesslich vorgegebene Funktionen, Methoden (im C++–Jargon) bzw. Schnittstellen (im COM/OLE-Jargon) zur Verfügung. Das Beschränken des Zugriffs auf die Nachrichtdeskriptoren und die darin enthaltenen globalen Zeiger stellt eine zusätzliche Sicherheitsmassnahme gegen die Speicherzerstörung über das TNet dar.
In einer Ausführungsform sind die folgenden Funktionen zur Handhabung von Nachrichten bzw. Nachrichtdeskriptoren verfügbar:

– den Umfang der Daten, auf die durch eine Nachricht verwiesen wird, zurückgeben (RETURN_MESSAGE_SIZE ());
– den Umfang der Daten, auf die durch eine Nachricht verwiesen wird, zurückgeben (RETURN_MESSAGE_SIZE ());
– einen Nachrichtdeskriptor in eine Vielzahl von Nach richtdeskriptoren aufteilen (DIVI-DE_MESSAGE_DESCRIPTOR());

DIVIDE_MESSAGE_DESCRIPTOR() nimmt als Argument einen Nachrichtdeskriptor und eine Anordnung bzw. Liste von Datenpufferspeichergrössen. Die Routine gibt eine Anordnung bzw. eine Liste von neulich zugewiesenen Nachrichtdeskriptoren zurück, welche denselben Pufferspeicherdeskriptor haben, deren Offsets und Längen jedoch so eingestellt sind wie in den Datenpufferspeichergrössen spezifiziert. Die neulich zugewiesenen Nachrichtdeskriptoren sind das Ergebnis von separaten Aufrufen von DUPLICA-TE_MESSAGE_DESCRIPTOR(), wobei die Benutzerdaten-Lesezeiger und -Längen an die von dem Benutzer angegebenen Spezifikationen angepasst werden. Somit haben der originale und alle kopierten Nachrichtdeskriptoren denselben Pufferspeicherdeskriptor als Bestandteil und der Referenzzählstand des bestandteilbildenden Pufferspeichers wird dementsprechend beeinflusst.
Wenn zum Beispiel md ptr einen Zeiger in einen Nachrichtdeskriptor für einen Datenumfang von 100 KB darstellt, so würde der Aufruf DIVIDE_MESSAGE_DESCRIPTOR(md ptr, 15, 50, 35, 0); eine Anordnung von drei Nachrichtdeskriptoren zurückgeben, wobei der erste mit seinem Benutzerlesedatenzeiger auf die ersten 15 Bytes der Daten verweisen würde, der zweite mit seinem Benutzerlesedatenzeiger auf die nächsten 50 Bytes der Daten verweisen würde und der letzte mit seinem Benutzerlesedatenzeiger auf die letzten 35 Bytes des Datenpufferspeichers verweisen würde. Die zugeordneten Längenfelder werden natürlich entsprechend dazu eingestellt.
Da alle vier Nachrichtdeskriptoren auf denselben Datenpufferspeicher verweisen, wird der Referenzzählstand des betreffenden Pufferspeichers um drei erhöht, angenommen von eins auf vier.
Schliesslich wird noch eine CONVERT_FOR_READ()-Routine bereitgestellt, die einen spezifizierten Nachrichtdeskriptor in einer beliebig konvertierten Form zurückgibt, welche für den Router, die Schnittstelleneinheit und die BÜM der aufrufenden DSQ erforderlich ist, damit diese die konkreten Daten lesen können, auf welche von dem globalen Zeiger in dem spezifizierten Nachrichtdeskriptor verwiesen wird. Die Daten werden von der Ursprungs-DSQ in die DSQ eingelesen, welche die Routine aufgerufen hat. (Es kann dazu eine entsprechende CONVERT-FOR-WRITE()-Routine existieren.)
Neue Betrachtungen zum Szenario 'Film auf Abruf'
Im folgenden wird erläutert, wie die weiter oben beschriebenen Datenstrukturen und Protokolle im Rahmen des vorgängig abgehandelten Szenarios 'Film auf Abruf' verwendet werden. Wenn bei der Beschreibung einer globalen WEA-Datenstruktur von dieser gesagt wird, dass sie von einer DSQ zu einer anderen bewegt wird, so stelle der Leser sich darunter vor, dass das weiter oben beschriebene, nachrichtbasierte Kommunikationssystem niedriger Ebene dazu benutzt wird, um die betreffende Datenstruktur zwischen den DSQs zu übertragen, und zwar typischerweise unter Verwendung der PUT_MESSAGE()-Routine.
Auch hier wird wieder davon ausgegangen, dass der Anwendungsserverprozess. 531 den Platenspeicherprozess 530 dazu verwendet, um die Daten 560 aus dem Plattenspeicher auszulesen, und dass er den Zwischenprotokollprozess 532 und den TCP/IP- & ATM-Prozess 533 dazu verwendet, um die Daten 560 zu der Benutzerschnittstelle weiterzuleiten. Auch hier wird wieder davon ausgegangen, dass der Anwendungsprozess 531 gewisse anwendungsspezifische Daten 561 am Anfang der abgehenden Daten 560 anhängt. Für die Grösse der Daten 560 werden 100 Kilobytes (KB) angenommen.
Jede DSQ, die an dem Daten-E/A-Schema durch Referenzierung teilnimmt, verfügt über eine globale WEA-Bibliothek. Der globale E/A-Speicher 580, das Plattenspeicherprozess-UVS 510, der Anwendungsserverprozess 511, das Zwischenprotokollprozess-UVS 512, das TCP/IP- & und das ATM-Treiber-UVS 513, sowie der ATM-Controller 570 rufen alle die CREATE_QUEUE()-Routine ihrer jeweiligen globalen WEA-Bibliothek auf, um Eingangswarteschlangen zum Empfang der globalen WEA-Nachrichten zu erzeugen. Der Dienst wird in jeder DSQ zum Beispiel "DATA_I/O" genannt. Dadurch wird es einer jeden DSQ auf dem TNet, die an. der Dateneingabe/-ausgabe durch Referenzierung beteiligt ist, ermöglicht, die WEA-Warteschlangen einer jeden anderen DSQ auf dem TNet, die ebenfalls an der Dateneingabe/-ausgabe durch Referenzierung beteiligt ist, zu beeinflussen.
Des weiteren ruft der Plattenspeicherprozess 530 seine globale WEA-Routine CREATE_QUEUE() auf, um Eingangs- und Ausgangswarteschlangen zur Aufnahme von "Disk-Work"- Anforderungen zu schaffen. Das Service wird beispielsweise "DiskWork" genannt. Dadurch wird es für jeden anderen Prozess auf dem Plattenspeicherprozess-UVS 510 und für jede DSQ auf dem TNet möglich, Arbeitsanforderungen in eine Warteschlange zu stellen, welche den Plattenspeicherprozess 530 anweisen, eine Lese- oder Schreiboperation auf dem mit dem Plattenspeicher-Controller 540 verbundenen Plattenspei cher vorzunehmen. Ein Prozess oder eine DSQ, welche (r) die von dem Plattenspeicherprozess 530 erzeugten, globalen WEA-Warteschlangen zu verwenden möchte, kennt den "DiskWork"-Namen der globalen WEA-Warteschlange.
Im Grunde stellt der Anwendungsserverprozess 531 eine Bearbeitungsanforderung des Plattenspeicherprozesses 530, indem er eine Plattenspeicherbearbeitungsanforderung in die globale "DiskWork"-WEA-Eingangswarteschlange einreiht. Die Bearbeitungsanforderung betrifft die Daten 560. Zuerst jedoch entscheidet der Anwendungsserverprozess 531, ob er selber oder der Plattenspeicherprozess 530 den für den Empfang der Daten 560 nötigen Datenpufferspeicher zuteilt.
Andererseits entscheidet, falls der Anwendungsprozess 531 es ist, der den Datenpufferspeicher zuteilt, der Anwendungsprozess 531 (jeweils gemäss den von seinem Programmierer festgelegten Regeln), die 100 KB an Daten 560 zum Beispiel in den globalen E/A-Speicher 580 zu stellen. Der Anwendungsprozess 531 führt daraufhin seine PUT_MESSAGE()-Routine aus, um in die globale "DATA_I/O"-WEA-Warteschlange des globalen E/A-Speichers 580 eine Anforderung zur Ausführung der GET_MESSAGE_DESCRIPTOR()-Routine des globalen E/A-Speichers 580 einzureihen. Der Anwendungsprozess 531 fordert dadurch einen globalen E/A-Speicher-Nachrichtdeskriptor auf einen Pufferspeicher mit einer Grösse von 100 KB an.
Der "DATA_I/O"-Treiber des globalen E/A-Speichers 580 führt die GET_MESSAGE()-Routine aus, um die Anforderung des Anwendungsprozesses 531 abzurufen, und führt schliesslich die GET_MESSAGE-DESCRIPTOR()-Routine aus, um die angeforderte Zuteilung vorzunehmen. Beim Fertigstellen der Anfor derung des Anwendungsserverprozesses 531 führt der "DATA_I/O"-Treiber des globalen E/A-Speichers 580 die PUT_MESSAGE()-Routine aus, um den soeben zugewiesenen, auf den 100 KB-Pufferspeicher verweisenden Nachrichtdeskriptor zurückzugeben. Die PUT_MESSAGE()-Routine stellt eine Kopie (der globalen Form) des Nachrichtdeskriptors in die globale "DATA_I/O"-WEA-Warteschlange. Der Anwendungsprozess 531 führt eine GET_MESSAGE-Routine aus, um die Kopie des soeben zugeteilten Nachrichtdeskriptors abzurufen, und kann daraufhin den globalen Benutzerdatenschreibzeiger in den Datenpufferspeicher in seine Bearbeitungsanforderung für die Daten 560 integrieren. Diese Bearbeitungsanforderung wird an den Plattenspeicherprozess 530 übertragen.
In Bezug auf Organisationsaufgaben macht die über DSQ-Grenzen hinweg ausgeführte PUT_MESSAGE()-Routine es erforderlich, dass die anfordernde DSQ eine (globale Form einer) Kopie der Nachricht an die empfangende DSQ sendet und dass eine RETURN_MESSAGE()-Routine ausgeführt wird. Die empfangende DSQ teilt ihrerseits einen Nachrichtdeskriptor zu, um die übertragene Kopie zu empfangen, und stellt den Nachrichtdeskriptor in die globale WEA-Warteschlange des Bestimmungsorts. Der Nachrichtdeskriptor wird also von einer Warteschlange in der sendenden DSQ in eine Warteschlagen in der empfangenden DSQ verschoben. Demgemäss sind die Referenzzählstände für die Pufferspeicherdeskriptoren der neuen Nachricht dieselben wie bei der sendenden DSQ, d. h. sie betragen eins.
In ähnlicher Weise wird der von dem GET_MESSAGE_DESCRIPTOR()-Aufruf zugeteilte Nachrichtdeskriptor von dem globalen E/A-Speicher 580 zu dem Anwendungsserverprozess-UVS 511 übertragen. Der Referenz zählstand des Pufferspeicherdeskriptors dieses Nachrichtdeskriptors beträgt ebenfalls eins.
Wenn es andererseits der Plattenspeicherprozess 530 ist, der den Pufferspeicher zuteilt, so kann der Anwendungsprozess 531 entweder in der Form eines Nachrichtenpakets oder in der Bearbeitungsanforderungs-Datenstruktur anzeigen, dass dem Plattenspeicherprozess 530 die Aufgabe zufällt, unter Verwendung seiner entsprechenden Verfahren den Datenpufferspeicher zuzuteilen. Der Anwendungsprozess 531 kann den Plattenspeicherprozess anweisen, den Pufferspeicher zuzuteilen, z. B. indem er das Adressfeld für den globalen TNet-Zeiger auf einen vorgegebenen Wert wie etwa NULL einstellt.
Während der Nachrichtdeskriptor die globale Adresse für den Bestimmungsort der Daten 560 bereit hält, weist der Plattenspeicherprozess 530 den Plattenspeicher-Controller 540 an, die Daten 560 von der Speicherplatte des Plattenspeicher-Controllers 540 zu dem Speicher 556 des globalen E/A-Speichers 580 zu übertragen. Bei der Übertragung der Daten 560 von dem Plattenspeicher-Controller 540 zu dem globalen E/A-Speicher 580 handelt es sich nicht um eine Dateneingabe/-ausgabe durch Referenzierung. Die Daten 560 werden nämlich unter Verwendung einer dem Bedarf entsprechenden Menge von HDAC-Paketen von dem Plattenspeicher-Controller 540 zu dem globalen E/A-Speicher 580 kopiert. Das Ergebnis der Übertragung besteht in einer weiteren Kopie der Daten 560, verglichen mit der vor der Übertragung vorhandenen Anzahl. Diese konventionelle Datenübertragung erfordert es, dass der Plattenspeicherprozess die Referenzierung des globalen Zeigers aufhebt, um eine tatsächliche Adresse zu erzeugen, welche der Plattenspeicherpro zess dann in seine Befehlssequenz für den Plattenspeicher-Controller 540 einfügt, so dass der Plattenspeicher-Controller 540 die Daten 560 an den globalen E/A-Speicher 580 übertragen kann. Diese neuerliche Referenzierung wird durch die weiter oben beschriebene CONVERT_FOR_WRITE()-Routine durchgeführt.
Der Plattenspeicher-Controller 540 unterbricht daraufhin (vorzugsweise in einer nachrichtbasierten Weise) den Plattenspeicherprozess 530, wenn die Übertragung vollständig ist. Der Plattenspeicherprozess 530 behandelt das Interrupt und leitet die Anforderung abschliessend an den Anwendungsserverprozess 531 zurück, indem er eine Rückantwort in die globale WEA-Warteschlange des Anwendungsserverprozesses 531 einreiht, die nötigenfalls die globale Adresse zu den Daten 560 (bzw. zu dem diese Daten enthaltenden Datenpufferspeicher) beinhaltet.
Der Anwendungsserverprozess 531 hat nun einen Nachrichtdeskriptor zur Verfügung, welcher einen Pufferspeicherdeskriptor beinhaltet, der mittels einer globalen Adresse auf den Pufferspeicher mit den Daten 560 verweist. Der globale Zeiger wurde in dem globalen E/A-Speicher 580 erzeugt, die Daten 560 befinden sich innerhalb des globalen E/A-Speichers 580, der Nachrichtdeskriptor selber jedoch befindet sich auf dem Anwendungsserver-UVS 511.
Der Anwendungsserver 531 hat bereits zuvor seine GET_MESSAGE_DESCRIPTOR()-Routine aufgerufen, um einen Nachrichtdeskriptor für seine anwendungsspezifischen Daten 561 zu erzeugen, und hat die nötigen Verarbeitungsschritte vorgenommen, um den zugeordneten Datenpufferspeicher mit den anwendungsspezifischen Daten 561 zu füllen. Der Anwendungs serverprozess 531 verknüpft nun die Daten 561, 560, indem er zwei Nachrichtdeskriptoren miteinander verkettet: einen Nachrichtdeskriptor für die anwendungsspezifischen Daten 561 im vorderen Teil der Kette, gefolgt von dem Nachrichtdeskriptor für die Daten 560. Der Nachrichtdeskriptor der anwendungsspezifischen Daten enthält die globale Adresse der anwendungsspezifischen Daten 561.
Da eine Funktion des Anwendungsserverprozesses 531 darin besteht, die anwendungsspezifischen Daten 561 allen Film-Clips, die der Prozess 531 zu unterschiedlichen Zeiten aus verschiedenen Speicherplatten abruft, voranzustellen, leitet der Prozess 531 vorzugsweise nicht den originalen, auf die Daten 561 verweisenden Nachrichtdeskriptor weiter. (Wenn er dies tun müsste, so müsste er eine Kopie der Daten 561 abrufen, die an jeden Film-Clip am Beginn anzuhängen sind.) Statt dessen ruft der Prozess 531 die DUPLICATE_MESSAGE_DESCRIPTOR()-Routine auf, um den auf die Daten 561 verweisenden Nachrichtdeskriptor zu kopieren. Der Referenzzählstand des Pufferspeicherdeskriptors dieses Nachrichtdeskriptors wird durch den Kopiervorgang um eins inkrementiert, beispielsweise von eins auf zwei.
Der Prozess 531 verkettet diesen kopierten Nachrichtdeskriptor vor den Nachrichtdeskriptor für die Daten 560, wodurch eine Nachricht erstellt wird, welche auf die Daten 561, 560 verweist. Der Prozess 531 führt daraufhin die PUT_MESSAGE()-Routine aus, um die aus den Daten 561, 560 bestehende Nachricht in das Zwischenprotokoll-UVS 512 zu verschieben. Wie bereits weiter oben erklärt, verschiebt die PUT_MESSAGE()-Routine die Nachricht (und seine zugeordneten Nachrichtdeskriptoren und Pufferspeicherdeskriptoren, jedoch nicht die Daten, auf die durch deren globale Refer enzierungszeiger verwiesen wird) von dem Anwendungsserver-UVS 511 zu dem Zwischenprotokoll-UVS 512. Auf dem Zwischenprotokoll-UVS 512 sind die Referenzzählstände der Pufferspeicherdeskriptoren der Nachricht dieselben wie sie auf dem Anwendungsserver waren, d. h. sie betragen zwei für den Nachrichtdeskriptor der anwendungsspezifischen Daten und eins für den Nachrichtdeskriptor der Daten 560.
Der Zwischenprotokollprozess 532 hat bereits zuvor seine GET_MESSAGE_DESCRIPTOR()-Routine aufgerufen, um einen Nachrichtdeskriptor für seine Protokolldaten 562 zu erzeugen, und ist mit den nötigen. Prozessen in Verbindung getreten, um den zugeordneten Datenpufferspeicher mit den Daten 562 zu füllen. Der Zwischenprotokollprozess 532 verknüpft die Daten 562, 561, 560, indem er drei Nachrichtdeskriptoren miteinander verkettet: eine Kopie des Nachrichtdeskriptors für die Protokolldaten 562 am Beginn der Kette, gefolgt von dem Nachrichtdeskriptor (in Kopie) für die Daten 561, gefolgt von dem Nachrichtdeskriptor für die Daten 560. Der Nachrichtdeskriptor für die Protokolldaten enthält die globale Adresse der Zwischenprotokolldaten 562 und eine Kopie des Nachrichtdeskriptors wird für Weiterleitungszwecke zugeteilt. Der Zwischenprotokollprozess führt daraufhin die PUT_MESSAGE()-Routine aus, um den Nachrichtdeskriptor und die Pufferspeicherdeskriptoren der Nachricht mit den Daten 562, 561, 560 (nicht jedoch die Daten 562, 561, 560 selber) in die globale TCP/IP & ATM Warteschlange im UVS 513 zu verschieben.
Die Nachricht wird von dem Zwischenprotokoll-UVS 512 zu dem TCP/IP- & ATM-UVS 513 bewegt. Auf dem UVS 513 betragen die Referenzzählstände des Pufferspeicherdeskriptors für die Daten 562, 561, 560 jeweils zwei, zwei und eins.
Der TCP/IP-Prozess 533 nimmt die aus drei Nachrichtdeskriptoren bestehende Nachricht und bereitet sie für das TCP/IP-Protokoll auf. Der Prozess 533 ruft die GET_MESSA-GE_SIZE()-Routine auf; um die Grösse der Nachricht zu berechnen, und erkennt dabei, dass diese Nachricht in drei TCP/IP-Pakete aufgegliedert werden muss. Das erste TCP/IP-Paket beinhaltet die Zwischenprotokoll-Headerdaten 562, die anwendungsspezifischen Daten 561 und den ersten Abschnitt der Film-Clip-Daten 560'. Das zweite Paket beinhaltet den zweiten Abschnitt der Filmdaten 560'', und das dritte Paket beinhaltet den Rest der Filmdaten 560'''. Der Prozess 633 bereitet drei TCP/IP-Header 563a, 563b, 563c vor, indem er dreimal die GET_MESSAGE_DESCRIPTOR()-Routine aufruft, um bedarfsgemäss Nachrichtdeskriptoren zuzuteilen.
Der Prozess 533 führt auch die DIVIDE_MESSAGE_DESCRIPTOR()-Routine aus, um die Daten 560 in die paketgrössengerechten Daten 560', 560'' und 560''' aufzuteilen.
Der Prozess 533 hat nun sechs Datenpufferspeicher, auf welche von neuen Nachrichtdeskriptoren verwiesen wird: drei TCP/IP-Header 563a, 563b, 563c; einen Zwischenprotokoll-Header 562; einen Anwendungs-Header 561; drei Datenblöcke 560', 560'' und 560''', sowie die Originaldaten 560. Die Datenblöcke 560, 560', 560'' und 560''' befinden sich alle in demselben Pufferspeicher.
Der TCP/IP- und ATM-Treiberprozess 533 verkettet diese Nachrichtdeskriptoren nun miteinander, um die oben beschriebenen drei TCP/IP-Pakete zu erzeugen, und verkettet die drei TCP/IP-Pakete untereinander zu einer Nachricht mit der folgenden Datensequenz: der TCP/IP-Header 563a, der Zwischenprotokoll-Header 562, die anwendungsspezifischen Daten 561, die Daten 560', der TCP/IP-Header 563b, die Daten 560'', der TCP/IP-Header 563c und die Daten 560'''. (Zu beachten ist, dass der Nachrichtdeskriptor für die Daten 560 selber in dieser neu geschaffenen Nachricht nicht in Erscheinung tritt.) Der ursprüngliche Pufferspeicherdeskriptor für den Nachrichtdeskriptor für den globalen Pufferspeicher 560 hat nun einen Referenzzählstand von fünf. Der Treiberprozess 533 verwendet die PUT_MESSAGE()-Routine, um diese acht Nachrichtdeskriptoren umfassende Nachricht an den ATM-Controller weiterzuleiten.
Der ATM-Controller 570 ist nun bereit, mit der Datenübertragung der Daten zu beginnen. Der Controller 570 geht die Liste der Deskriptoren durch und überträgt nun die tatsächlichen Daten von einer jeden der DSQs, in der entsprechende Daten vorhanden sind. Für die vier Nachrichtdeskriptoren des ersten Pakets handelt es sich bei den Datenquellen um den Speicher 553 des TCP/IP-Treiber-UVS, um den Speicher 552 des Zwischenprotokoll-UVS, um den Speicher 551 des Anwendungsserver-UVS und um den globalen E/A-Speicher 580. Der ATM-Controller ruft der Reihe nach an jedem der Nachrichtdeskriptoren die CONVERT_FOR_READ-Routine auf und erzeugt dadurch TNet-weite Leseanforderungen. Die HDACs werden per direktem Speicherzugriff durch die BÜM (nicht gezeigt) des ATM-Controllers in einer an den Datenbedarf des ATM-Controllers 570 angepassten Art verarbeitet, und das FIFO (nicht gezeigt) des ATM-Controllers 570 nimmt die abgerufenen Daten auf, bis der ATM-Chipsatz (nicht gezeigt) und das ATM-Protokoll für sie bereit sind.
Der ATM-Controller 570 beendet die Übertragung sämtlicher Daten für das erste ATM-Paket und ruft daraufhin die RETURN_MESSAGE_DESCRIPTORS-Routine auf, um die Nachrichtdeskriptoren für dieses erste Paket zurückzugeben. (Der ATM-Controller benachrichtigt daraufhin das ATM-Treiber-UVS per Interrupt von diesem Umstand.)
Das ATM-Treiber-UVS 513 gibt einen jeden der Nachrichtdeskriptoren des ersten Pakets mittels eines globalen, RETURN_MESSAGE_DESCRIPTOR()-WEA-Aufrufs zurück. Die Rückgabe des auf die ersten TCP/IP-Headerdaten 563a verweisenden Nachrichtdeskriptors bewirkt, dass der Nachrichtdeskriptor sowie der Datenpufferspeicher und der Pufferspeicherdeskriptor, welche letzteren darstellen, innerhalb des UVS 513 unverzüglich freigegeben werden, da sie dort zugeteilt worden waren und der Referenzzählstand des Pufferspeicherdeskriptors eins betrug. (Mit anderen Worten, der Nachrichtdeskriptor war niemals Gegenstand einer DUPLICATE_MESSAGE_DESCRIPTOR()-Routine sondern nur von PUT_MESSAGE()-Routinen.)
Die Rückgabe des auf die Zwischenprotokoll-Headerdaten 562 verweisenden Nachrichtdeskriptors an das Zwischenprotokoll-UVS 512 vermindert den Zählstand des Pufferspeicherdeskriptors auf eins. Daher kann dieser Pufferspeicherdeskriptor noch nicht freigegeben werden. (Der zurückgegebene Nachrichtdeskriptor war als Ergebnis einer DUPLICATE_MESSAGE_DESCRIPTOR()-Routine zustandegekommen, wodurch der Referenzzählstand des Pufferspeicherdeskriptors auf zwei gesetzt worden war.) Der Zwischenprotokollprozess 532 kann den auf die Daten 562 verweisenden Nachrichtdeskriptor beim nächsten Mal, wenn das Zwischenprotokoll benötigt wird, wieder verwenden.
Die Rückgabe des auf die anwendungsspezifischen Daten 561 verweisenden Nachrichtdeskriptors vermindert den Referenzzählstand seines Pufferspeicherdeskriptors gleichermassen auf eins. Der Anwendungsserverprozess kann den auf den Datenpufferspeicher 561 verweisenden Nachrichtdeskriptor beim nächsten Mal, wenn die anwendungsspezifischen Daten benötigt werden, wieder verwenden.
Die Rückgabe des auf den ersten Abschnitt der Plattenspeicherdaten 560' verweisenden Nachrichtdeskriptors an den globalen E/A-Speicher 580 bewirkt schliesslich, dass der Referenzzählstand des. Pufferspeicherdeskriptors für die Plattenspeicherdaten 560, 560', 560'' um eins auf vier vermindert wird.
Die Übertragung der Daten in den Nachrichtdeskriptoren des zweiten Pakets und die Rückgabe dieser Nachrichtdeskriptoren erfolgen analog zu dem ersten Paket. Auf eine detaillierte Beschreibung wird daher hier verzichtet, um Wiederholungen zu vermeiden.
Schliesslich beendet der ATM-Controller 570 die Übertragung aller Daten für das dritte und letzte ATM-Paket. Er ruft die PUT_MESSAGE()-Routine auf, um die Nachrichtdeskriptoren für dieses dritte Paket zurückzugeben (und unterbricht das ATM-Treiber-UVS 513). Der ATM-Treiberprozess 533 verarbeitet die Rückgabe eines jeden der Nachrichtdeskriptoren. Unterschiede zu der Rückgabeverarbeitung für das erste Paket liegen in erster Linie darin, dass bei dem letzten Paket der Referenzzählstand für die Daten 560 auf eins vermindert worden ist.
Die Rückgabe des auf die Plattenspeicherdaten 560 verweisenden Nachrichtdeskriptors umfasst die Rückgabe des auf den globalen E/A-Speicher 580 verweisenden Nachrichtdeskriptors, welcher den Pufferspeicher ursprünglich für seinen aktuellen Gebrauch zugewiesen hat. Der Referenzzählstand des Pufferspeicherdeskriptors für die Daten 560 fällt von eins auf null zurück. Die Zuteilung des Nachrichtdeskriptors sowie des diesen konstituierenden Pufferspeicherdeskriptors und des Datenpuffers wird rückgängig gemacht und die betreffenden Elemente kehren zu ihren jeweiligen freien Pools zurück. Wenn die Daten 560 zu einem späteren Zeitpunkt wieder verwendet werden sollen, so müssen sie erneut aus dem Plattenspeicher-Controller 540 ausgelesen werden.
Wie für Personen mit einschlägigen Fachkenntnissen ersichtlich ist, fand in einem System, in welchem mehrere Prozessoren seriell zur Übertragung von Daten von dem Plattenspeicher-Controller 570 zu dem ATM-Controller eingesetzt wurden und in welchem drei der Prozessoren, 511, 512, 513 zur Bereitstellung der an den ATM-Controller weitergeleiteten Daten beitrugen, jeweils nur eine Übertragung jedes einzelnen Datenelements statt – und zwar von den jeweiligen Ursprungsorten (dem globalen E/A-Speicher 580, den UVS 511, 512, 513) der Daten (560, 561, 562, 563) an den endgültigen Bestimmungsort (den ATM-Controller 570) der Daten.
Somit wird eine Vorrichtung und ein Verfahren zur Durchführung einer Dateneingabe/-ausgabe durch Referenzierung zwischen mehreren Datenquellen und -senken offengelegt. Das Verfahren eignet sich insbesondere für Video-auf-Bestellung- und andere Mulitmedia-Anwendungen. Die Vorteile der Dateneingabe/-ausgabe durch Referenzierung liegen unter anderem in einer besseren Parallelverarbeitung, in einer besseren linearen Funktionssicherheit, in der Nutzung von Hochgeschwindigkeitsnetzwerken und in der Möglichkeit des Einsatzes von speziellen, funktionsspezifischen Prozessoren.
Der Programmtext für eine Software der hier offenbarten Art kann natürlich in statischer Form auf einem magnetischen, optischen oder sonstigen Plattenspeicher, auf einem Magnetband oder einem anderen Medium vorhanden sein, das eine Datenbewegung zum Zweck des Speicherns und Abrufens von Daten in einem Festwertspeicher, einem Direktzugriffsspeicher oder einem sonstigen Datenspeichermedium erforderlich macht. Dieses Datenspeichermedium kann entweder fix in das System integriert oder in dieses einfügbar sein.

Claims

Verfahren zur Transformation eines Datenstroms in einem Datenverarbeitungssystem (500), dessen Speicher eine aufgeteilte Struktur aufweist, die eine Vielzahl von Datenquellen/senken (510...513, 540, 570, 580) in Form von CPUs oder I/O-Controllern, die als Knoten mit einem Netzwerk (520) verknüpft sind, mit zugeordneten Speichern umfasst, mit Datenorten, die anhand der Speicheradresse über das Netzwerk zugänglich sind, wobei das Verfahren durch folgende Schritte gekennzeichnet ist: Erzeugen eines ersten Deskriptors für erste Daten einer ersten Datenquelle/senke (580); Übertragen des ersten Deskriptors zu einer zweiten Datenquelle/senke (513), ohne die ersten Daten zu übertragen; Unterteilen des ersten Deskriptors in eine Vielzahl von Deskriptoren, wobei jeder aus der Vielzahl von Deskriptoren einen Teil der ersten Daten beschreibt; Übertragen von einem aus der Vielzahl von Deskriptoren von der zweiten Datenquelle/senke (513) zu einer dritten Datenquelle/senke (570); und Abrufen desjenigen Teils der ersten Daten, der vom einen Deskriptor der ersten Datenquelle/senke (580) beschrieben wird, zur dritten Datenquelle/senke (570) zur Durchführung einer Dateneingabe/ausgabe.
Verfahren nach Anspruch 1, wobei der erste Deskriptor eine erste globale Netzwerkadresse einschließt, die einen ersten Speicherort fest legt, wo ein erster Datenstrom gespeichert wird.
Verfahren nach Anspruch 2, das außerdem, nach dem Schritt der Erzeugung eines ersten Deskriptors, den folgenden Schritt umfasst: Erzeugen, in einer vierten Datenquelle/senke (511), eines zweiten Deskriptors, der eine zweite globale Netzwerkadresse einschließt, die einen zweiten Speicherort fest legt, wo ein zweiter Datenstrom gespeichert wird, und Verketten der ersten und zweiten Deskriptoren unter Bildung eines ersten verketteten Deskriptors, und Übertragen des ersten verketteten Deskriptors zur zweiten Datenquelle/senke (513).
Verfahren nach Anspruch 2, das außerdem umfasst den Schritt der Verarbeitung des ersten Deskriptors an der dritten Datenquelle/senke (570) zu einer Vielzahl sekundärer Deskriptoren, um den ersten Datenstrom in Teile aufzuspalten, und die Verkettung eines jeden Teils des ersten Datenstroms mit Anfangskennsätzen zum Protokoll.
Verfahren nach Anspruch 4, das außerdem folgenden Schritt umfasst: Erzeugen globaler I/O-Warteschlangen an den ersten, zweiten und dritten Datenquellen/senken (580, 513, 570); und wobei der Schritt der Übertragung des ersten Deskriptors zur zweiten Datenquelle/senke (513) folgende Schritte umfasst: Ablegen des ersten Deskriptors in der globalen I/O-Warteschlange bei der ersten Datenquelle/senke (580); und Queuing des ersten Deskriptors von der globalen I/O-Warteschlange bei der ersten Datenquelle/senke zur globalen I/O-Warteschlange bei der zweiten Datenquelle/senke, was dazu führt, dass nur der erste Deskriptor in die zweite Datenquelle/senke kopiert wird.
Verfahren nach Anspruch 1, das außerdem folgende Schritte umfasst: Zurückführen des ersten Deskriptors zur ersten Datenquelle/senke (580); und Freigabe des Speicherplatzes des ersten Deskriptors und des beschriebenen Speicherbereichs.
Verfahren nach Anspruch 1, wobei der Schritt des Übertragens des ersten Deskriptors zu einer zweiten Datenquelle/senke (513) folgende Schritte umfasst: Duplizieren des ersten Deskriptors, dadurch Erzeugen eines Deskriptorduplikats und Inkrementieren eines Zählers der ersten Daten; und Übertragen von einem des ersten Deskriptors und Deskriptorduplikats zur zweiten Datenquelle/senke.
Verfahren nach Anspruch 7, das außerdem folgende Schritte umfasst: Vernichten des Deskriptorduplikats; und Dekrementieren des Zählers.
Computerprogrammprodukt, das ein computerlesbares Medium umfasst, das einen Code für ein Computerprogramm enthält, der so adaptiert ist, dass, wenn das Pro gramm einem Computer eingegeben wird, der Computer das Verfahren eines beliebigen der Ansprüche 1 bis 8 ausführt.
Computerprogramm, verfügbar über eine elektronische Datenübertragung, das einen Code für ein Computerprogramm enthält, der so adaptiert ist, dass, wenn das Programm einem Computer geladen wird, der Computer das Verfahren eines beliebigen der Ansprüche 1 bis 8 ausführt.