DE69331024T2

DE69331024T2 - Verfahren und Vorrichtungen zur Bildung von Protokollen

Info

Publication number: DE69331024T2
Application number: DE69331024T
Authority: DE
Inventors: Gerard Johan Holzmann
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1992-02-10
Filing date: 1993-02-04
Publication date: 2002-07-11
Anticipated expiration: 2013-02-05
Also published as: ES2162805T3; KR930018395A; JPH066406A; TW241428B; CA2088395C; EP0555997A2; CA2088395A1; EP0555997B1; US5826017A; KR100272908B1; EP0555997A3; DE69331024D1

Description

Hintergrund der Erfindung

Technisches Gebiet

Die Erfindung betrifft die Kommunikation in verteilten Systemen allgemein und insbesondere Protokolle.

Stand der Technik

Ein Computerprotokoll ist eine Menge von Regeln für die Wechselwirkung gleichzeitiger Prozesse in einem verteilten Datenverarbeitungssystem. Wenn zum Beispiel der Computer A, der mit einem Plattenlaufwerk, das Dateien enthält, verbunden ist, eine dieser Dateien auf einem mit dem Computer B verbundenen Drucker ausdrucken möchte, so ist dies nur möglich, wenn sich Computer A mit Computer B auf ein Protokoll dafür geeinigt hat. Das Protokoll muß zum Beispiel die folgenden Angelegenheiten definieren:
- Wie fragt Computer A den Computer B, ob der Drucker verfügbar ist?
- Wie sagt Computer B dem Computer A, daß der Drucker verfügbar ist oder nicht?
- Wie sagt Computer A dem Computer B, daß er mit dem Senden von Daten beginnt?
- Wie teilt Computer B dem Computer A mit, die Geschwindigkeit zu verlangsamen, mit der Computer A Daten sendet, oder mit dem Senden aufzuhören?
- Wie teilt Computer B dem Computer A mit, das Senden wiederaufzunehmen?
- Wie sagt Computer A dem Computer B, daß er mit dem Senden fertig ist?
- Wie sagt Computer B dem Computer A, daß er mit dem Drucken fertig ist?
Eine allgemeine Besprechung von Computerprotokollen findet sich in Gerard J. Holzmann, Design and Validation of Computer Protocols, Prentice Hall, Englewood Cliffs, NJ, 1991.
Zu den Schwierigkeiten der Implementierung von Computerprotokollen gehören die Schwierigkeiten, die Folgen des Umstands sind, daß die Elemente, die ein Protokoll ausführen, häufig verschieden sind. Zum Beispiel können Computer A und Computer B in dem obigen Beispiel verschiedene Arten von Maschinen sein. In anderen Fällen können die Elemente, die das Protokoll ausführen, Programme sein, die in verschiedenen Programmiersprachen geschrieben wurden. Da jedes der Elemente, die zusammenwirken, um das Protokoll auszuführen, eine Implementierung mindestens seines Teils des Protokolls enthalten muß, gibt es soviele verschiedene Implementierungen von mindestens Teilen des Protokolls, wie es verschiedene zusammenwirkende Elemente gibt.
Eine der Schwierigkeiten, die durch diese Situation entstehen, ist die Notwendigkeit, jedes Protokoll für jede Art von Element, die es ausführt, neu zu implementieren. Mit wachsender Anzahl von Protokollen und Arten von Elementen entsteht mehr und mehr Implementierungsaufwand. Eine noch wichtigere Schwierigkeit wird durch den Umstand verursacht, daß die Implementierungen desselben Protokolls für verschiedene Elemente häufig von verschiedenen Personen durchgeführt werden; wenn. die verschiedenen Personen verschiedene Auffassungen des Protokolls haben, dann sind die Implementierungen möglicherweise nicht völlig kompatibel, und es ist schwer, zu bestimmen, inwieweit sie inkompatibel sind und wie sich etwaige Inkompatibilitäten auswirken.
Die im folgenden besprochenen Vorrichtungen und Verfahren überwinden diese und andere Probleme, indem allen Elementen, die ein Protokoll ausführen, gestattet wird, dieselbe Beschreibung des Protokolls auszuführen.
Aus EP-A-0 289 248 ist eine programmierbare Protokollmaschine bekannt, die einen zentralen Kernprozessor aufweist, der mehrere programmierbare Automaten die kontextabhängige Operationen durchführen, und programmierbare Satelliten-Verarbeitungseinheiten, die kontextfreie Operationen durchführen, implementiert. Zur Unterstützung der Pufferung der zweiseitigen Kommunikationen der Protokollmaschine wird ein Speicher hinzugefügt, der mit dem zentralen Prozessor und den Satelliteneinheiten in Wechselwirkung tritt. Die Programmierbarkeit der Protokollmaschine wird dadurch erzielt, daß die Satelliteneinheiten mit Kombinationen einer Verarbeitungseinheit und einer Speichereinheit, die die durch die entsprechende Verarbeitungseinheit durchzuführenden Anweisungen speichert, realisiert wird. Die Folge von auszuführenden Anweisungen wird einer kleinen einzigartigen Menge von Anweisungen entnommen, die speziell an die Aufgaben angepaßt sind, die Protokollimplementierungen zugeordnet sind. Zum Laden der notwendigen Anweisungen in die Satelliteneinheiten und den Zentralprozessor werden Anweisungsports bereitgestellt, wodurch ein gewähltes Protokoll implementiert wird. Um die Verwendung der Protokollmaschine in Umgebungen zu gestatten, in denen mehrere Benutzer auf eine einzige physische Strecke gemultiplext werden, werden zusätzliche Mittel zur Speicherung des Zustands der Automaten in dem zentralen Prozessor und zur Wiederherstellung einer zuvor gespeicherten Menge von Zuständen des Automaten bereitgestellt.

Kurze Darstellung der Erfindung

In einem Aspekt der Erfindung handelt es sich bei der Erfindung um Peripherievorrichtungen zur Übermittlung von Informationen unter Verwendung eines Protokolls. Die Vorrichtung enthält folgendes:
- Mittel zum Übermitteln der Informationen gemäß dem Protokoll;
- Mittel zum Übermitteln der Informationen zwischen der Peripherievorrichtung und einem Host-Gerät;
- von dem Host-Gerät unabhängige Mittel zum Speichern einer Protokollbeschreibung, die das Protokoll beschreibt und die eine Protokollbeschreibungssprache verwendet, die von jeder bestimmten Implementierung der Peripherievorrichtung unabhängig ist; und
- ein Protokollbeschreibungsinterpretationsmittel, das von dem Host-Gerät unabhängig ist und die Protokollbeschreibungssprache interpretieren kann, zum Interpretieren der Protokollbeschreibung, so wie es zur Übermittlung der Informationen gemäß dem Protokoll über das Mittel zum Übermitteln der Informationen gemäß dem Protokoll und zum Übermitteln der Informationen über das Mittel zur Bereitstellung der Informationen für das Host- Gerät erforderlich ist.
In einem anderen Aspekt ist die Erfindung ein Kommunikationsverfahren in einem verteilten System. Das Verfahren enthält die folgenden Schritte:
- in einem ersten Element des verteilten Systems,
- Empfangen einer ersten allgemeinen Protokollnachricht, die eine Protokollbeschreibung enthält, die ein spezifisches Protokoll beschreibt, wobei die Protokollbeschreibung eine Protokollbeschreibungssprache verwendet, die von jeder bestimmten Implementierung des ersten Elements unabhängig ist; und
- Reagieren auf die erste allgemeine Protokollnachricht, indem ein erstes Protokollbeschreibungsinterpretationsmittel verwendet wird, das die Protokollbeschreibungssprache interpretieren kann, um die Protokollbeschreibung so zu interpretieren, wie es zur Kommunikation unter Verwendung des spezifischen Protokolls erforderlich ist.
In noch einem Aspekt ist die Erfindung eine Protokollvorrichtung zur Kommunikation in verteiltem System, umfassend:
- Mittel zum Empfangen einer ersten allgemeinen Protokollnachricht, wobei die erste allgemeine Protokollnachricht eine Protokollbeschreibung enthält, die ein spezifisches Protokoll beschreibt und die eine Protokollbeschreibungssprache verwendet, die von jeder bestimmten Implementierung der Protokollvorrichtung unabhängig ist; und
- Mittel zum Reagieren auf die erste allgemeine Protokollnachricht, die die Protokollbeschreibungssprache interpretieren können und die die Protokollbeschreibung so interpretieren, wie es zur Kommunikation unter Verwendung des spezifischen Protokolls erforderlich ist.
In einem weiteren Aspekt ist die Erfindung eine Vorrichtung zur Kommunikation in einem verteilten System, umfassend:
- eine erste Protokollvorrichtung zur Kommunikation unter Verwendung eines allgemeinen Protokolls und
- eine zweite Protokollvorrichtung zur Kommunikation unter Verwendung des allgemeinen Protokolls,
- wobei die erste Protokollvorrichtung folgendes enthält:
- Mittel zum Bereitstellen einer ersten allgemeinen Protokollnachricht, die eine Protokollbeschreibung enthält, die ein spezifisches Protokoll beschreibt und die eine Protokollbeschreibungssprache verwendet, die von jeglicher bestimmten Implementierung der zweiten Protokollvorrichtung unabhängig ist; und
- Mittel zum Verwenden des spezifischen Protokolls, um nach der Bereitstellung der ersten allgemeinen Protokollnachricht mit der zweiten Protokollvorrichtung zu kommunizieren; und
- wobei die zweite Protokollvorrichtung folgendes enthält:
- Mittel zum Empfangen der ersten allgemeinen Protokollnachricht aus der ersten Protokollvorrichtung; und
- Mittel zum Reagieren auf die erste allgemeine Protokollnachricht, die die Protokollbeschreibungssprache interpretieren können und die die Protokollbeschreibung so interpretieren, wie es zur Kommunikation unter Verwendung des spezifischen Protokolls erforderlich ist.
Die obigen und weitere Aspekte, Aufgaben und Vorteile der Erfindung werden Durchschnittsfachleuten bei Durchsicht der folgenden Zeichnung und ausführlichen Beschreibung deutlich. Es zeigen:

Kurze Beschreibung der Zeichnung

Fig. 1 ein Blockschaltbild eines typischen Systems, indem Protokolle verwendet werden;
Fig. 2 ein Blockschaltbild einer ersten Vorrichtung, in die die Erfindung integriert ist;
Fig. 3 ein Blockschaltbild einer zweiten Vorrichtung, in die die Erfindung integriert ist;
Fig. 4 eine Tabelle von Anweisungen in einer Protokollbeschreibungssprache;
Fig. 5 ein Flußdiagramm des bootstrap-Zustands;
Fig. 6 ein Flußdiagramm des Fehlerzustands;
Fig. 7 ein Zustandsdiagramm für das Abwechslungsbitprotokoll;
Fig. 8 eine Protokollbeschreibung für die Empfangsseite des Abwechslungsbitprotokolls;
Fig. 9 eine Protokollbeschreibung für die Sendeseite des Abwechslungsbitprotokolls;
Fig. 10 ein Fragment der Prozedur transition;
Fig. 11 eine Protokollbeschreibung für den
bootstrap-Zustand;
Fig. 12 eine Protokollbeschreibung für den Fehlerzustand; und
Fig. 13 ein Blockschaltbild einer Ausführungsform, bei der heruntergeladene Protokollbeschreibungen in Cache-Speichern gespeichert werden.
Die in der Zeichnung und in der ausführlichen Beschreibung verwendeten Bezugszahlen haben drei oder mehr Stellen. Die beiden niedrigstwertigen Stellen sind eine Nummer in einer Figur; die übrigen Stellen sind die Nummer der Figur. Somit wird das Element mit der Bezugszahl "305" zuerst in Fig. 3 gezeigt.

Ausführliche Beschreibung

Die folgende ausführliche Beschreibung gibt zunächst eine Übersicht der Techniken der Erfindung und zeigt dann im einzelnen, wie das Abwechslungsbitprotokoll (siehe Holzmann, supra, S. 75-77) mit den Techniken der Erfindung implementiert werden kann.

Übersicht: Fig. 1-3

Fig. 1 ist ein Blockschaltbild eines Systems 101, in dem zur Kommunikation zwischen einem ersten Element 109(1) und einem zweiten Element 109(2) Protokolle verwendet werden. Jedes Element 109 enthält eine Quelle oder ein Ziel 103 für Informationen (INFO) 105 und eine Protokollvorrichtung 107.
Wie durch die Pfeile gezeigt, verlaufen bei der Kommunikation des Elements 109(1) mit dem Element 109(2) Informationen 105 von der Quelle 103(1) zu der Protokollvorrichtung (PA) 107(1), die ein Protokoll wie oben beschrieben verwendet, um Informationen 105 zu der Protokollvorrichtung 107(2) zu übermitteln. Wie bereits erläutert führt die Verbindung zwischen der Protokollvorrichtung 107(1) und der Protokollvorrichtung 107(2) nicht nur Informationen 105, sondern auch die Steuerinformationen 109, die die Protokollvorrichtung 107(1) und 107 (2) benötigen, um das Protokoll auszuführen. Die Informationen 105 und die Steuerinformationen 109 bilden zusammen die Protokolldaten (PDATA) 111. Die Protokollvorrichtung 107(2) liefert die Informationen 105, die sie empfängt, dann an das Ziel 103(2). Wenn das Element 109 (2) mit dem Element 109 (1) kommuniziert, erreichen die Informationen 105 aus der Quelle 103(2) die Protokollvorrichtung 107(2), die Protokollvorrichtungen 107 (1) und 107 (2) führen das Protokoll aus, das dieses Mal die Informationen aus der Protokollvorrichtung 107 (2) zu der Protokollvorrichtung 107 (1) übermittelt, und die Protokollvorrichtung 107(1) liefert die Informationen an das Ziel 103(1).
Ein System des in Fig. 1 gezeigten Typs kann auf vielfältige Weise aufgebaut werden und kann in vielen Umgebungen verwendet werden. Zum Beispiel können die Protokollvorrichtung 107(1) und 107(2) mit einer beliebigen Art von Kommunikationsmedium verbunden werden, wie zum Beispiel parallele und serielle Busse, Telekommunikationsmedien und gemeinsam benutzte Speicher. Außerdem können die Elemente 109 Prozesse sein, die in einem einzigen System ablaufen, oder Prozesse, die in verschiedenen Systemen ablaufen.
Außerdem kann die Kommunikation zwischen verschiedenen Ebenen desselben Systems oder zwischen verschiedenen Systemen erfolgen. Als letztes kann die Vorrichtung 107 in einem Prozeß implementiert werden, der in einem Mehrfachprozeßsystem oder in Spezialhardware oder in Kombinationen dieser Alternativen abläuft.
Da der Zweck eines Protokolls darin besteht, zwischen verschiedenen Elementen 109 zu kommunizieren, und die Protokollvorrichtung 107 in jedem Fall Teil des Elements 109 ist, ist es fast immer der Fall, daß die Protokollvorrichtung 107(1) und die Protokollvorrichtung 107(2) von verschiedenen Personen implementiert werden. Diese Tatsache hat wichtige Konsequenzen. Wie bei Holzmann, supra, erläutert wird, ist es äußerst schwierig, eine Beschreibung eines Protokolls zu geben, die sowohl vollständig als auch unzweideutig ist. Wenn die Beschreibung unvollständig oder zweideutig ist, implementieren verschiedene Personen die Protokollvorrichtung 107, die verschiedene Versionen des Protokolls ausführt, und wenn zwei Protokollvorrichtungen 107, die verschiedene Versionen des Protokolls ausführen, versuchen, unter Verwendung des Protokolls zu kommunizieren, kann die Kommunikation ausfallen. Schlimmer ist, daß die Art des Ausfalls, da die Ausfälle die Ergebnisse verschiedener Interpretationen der Protokollbeschreibung sind, unvorhersehbar ist und deshalb beim Entwurf des Protokolls nicht berücksichtigt werden kann. Obwohl eine vollständige und unzweideutige Protokollbeschreibung das Problem vermindern kann, wird es dadurch nicht beseitigt. Die Personen, die die Vorrichtung 107 implementieren, können die Protokollbeschreibung immer noch verschieden auffassen, und ihre Implementierungen der Vorrichtung 107 werden diese Auffassungen wiedergeben. Wiederum ist das Ergebnis die Implementierung der Protokollvorrichtungen 107, die verschiedene Versionen des Protokolls ausführen, und wiederum besteht das Risiko, daß die Kommunikationen zwischen Elementen, die diese Vorrichtungen 107 verwenden, ausfallen.
Fig. 2 zeigt eine Protokollvorrichtung 201, die das obige Problem löst. Die Protokollvorrichtung 201 besitzt zwei Hauptkomponenten: die Protokollbeschreibung 203 und die Protokollausführungsvorrichtung 207. Die Protokollbeschreibung 203 ist eine Protokollbeschreibung, die unter. Verwendung von Protokollanweisungen 205 geschrieben wurde, die zu einer Protokollbeschreibungssprache gehören. Die Protokollbeschreibungssprache ist unabhängig von jeglicher bestimmten Hardware- oder Softwareimplementierung der Protokollvorrichtung 201. Es gibt eine einzige Protokollbeschreibung 203 für das Protokoll und jede Protokollvorrichtung 201 besitzt eine Kopie eines Teils der einzigen Protokollbeschreibung 203 oder der gesamten einzigen Protokollbeschreibung 203. Die Protokollausführungsvorrichtung 207 führt das Protokoll aus, indem sie die Protokollanweisungen in der Protokollbeschreibung 203 ausführt. Die Protokollanweisungen 205 werden mittels eines Protokollanweisungsinterpretierers 209 ausgeführt. Der Protokollanweisungsinterpretierer 209 kann alle zu der Protokollbeschreibungssprache gehörenden Anweisungen interpretieren. Bei der Interpretation jeder Anweisung erzeugt er Steuerausgaben 213 für die zugrundeliegende Einrichtung 211, die tatsächlich Informationen 105 empfängt und Protokolldaten 111 liefert. Die zugrundeliegende Einrichtung 211 kann wiederum Steuereingaben 214 für den Protokollspracheninterpretierer 209 liefern. Die zugrundeliegende Einrichtung 211 kann in Software, Hardware oder einer Kombination von Software und Hardware implementiert werden. Abhängig davon, wie die zugrundeliegende Einrichtung 211 implementiert wird, können Steuerausgaben 213 Prozeduraufrufe oder Subroutinenadressen, Übermittlungen zwischen Prozessen, Anweisungen für einen Prozessor in der zugrundeliegenden Einrichtung 211 oder Steuerausgaben für Hardwareeinrichtungen enthalten. Im letzteren Fall kann die Protokollausführungseinrichtung 207 ein spezialisierter Mikroprozessor sein, der Anweisungen in der Protokollbeschreibungssprache ausführt. Abhängig davon, wie die zugrundeliegende Einrichtung 211 implementiert wird, können Steuereingaben 214 von einer Prozedur oder einer Subroutine zurückgegebene Daten, von einer Übermittlung zwischen Prozessen zurückgegebene Daten, die Ergebnisse von Ausführungen von Anweisungen oder von Interrupts enthalten.
Eine Implementierung der Protokollvorrichtung 201, die besonders vorteilhaft ist, ist eine Implementierung als ein Peripheriegerät für eine Quelle oder ein Ziel 103 wie zum Beispiel einen Hostcomputer. Eine solche Implementierung würde zwischen das Medium, über das die Protokolldaten 111 übermittelt werden sollen, und einen Bus des Hostcomputers geschaltet und würde ihren eigenen Speicher zum Speichern der Protokollbeschreibung 203 und ihre eigene Protokollausführungseinrichtung 207 enthalten. Bei einer solchen Implementierung könnte die Protokollausführungseinrichtung 207 als ein Prozessor implementiert werden, der Protokollanweisungen 205 direkt ausführen kann. Eine besonders vorteilhafte Form eines solchen Peripheriegeräts wäre eine Implementierung in einer einzigen integrierten Schaltung.
Die Protokollvorrichtung 201 weist gegenüber der Protokollvorrichtung 107 zahlreiche Vorteile auf. Erstens verwendet jede Protokollvorrichtung 201 eine Kopie der einzigen Protokollbeschreibung 203; deshalb ist es nicht möglich, daß verschiedene Implementierungen der Protokollvorrichtungen 201 verschiedene Versionen des Protokolls implementieren. Zweitens wird die Protokollbeschreibung 203 nur einmal geschrieben, aber viele Male verwendet. Es ist es deshalb Wert, große Bemühungen aufzuwenden, um sicherzustellen, daß die Protokollbeschreibung 203 tatsächlich eine korrekte, vollständige und unzweideutige Beschreibung des Protokolls ist. Drittens ist der Teil der Protokollvorrichtung 201, der bei den verschiedenen Implementierungen unterschiedlich sein kann, die Protokollausführungseinrichtung 207. Die Protokollausführungseinrichtung 207 muß nun aber in der Lage sein, die Protokollanweisungen 205 in der Protokollbeschreibung 203 korrekt auszuführen. Das heißt, das Problem ist nicht mehr die korrekte Implementierung des Protokolls, sondern die korrekte Implementierung eines Anweisungssatzes in einer einzigen Einrichtung. Dieses Problem ist jedoch wesentlich besser verständlich als das Problem der Implementierung eines Protokolls in zwei Einrichtungen, und die Implementierungen des Protokollanweisungssatzes in verschiedenen Protokollvorrichtungen 201 sind deshalb wesentlich wahrscheinlicher korrekt als Implementierungen des Protokolls selbst.

Vorrichtung zur Ausführung eines allgemeinen Protokolls: Fig. 3 und 13

Der bedeutendste Vorteil der Protokollvorrichtung 201 ist vielleicht, daß sie ein beliebiges Protokoll ausführen kann, für das eine in der Protokollbeschreibungssprache geschriebene Protokollbeschreibung 203 vorliegt. Folglich kann die Protokollvorrichtung 201 leicht modifiziert werden, um eine allgemeine Protokollvorrichtung herzustellen, die ein allgemeines Protokoll ausführt, und die deshalb dynamisch jedes beliebige Protokoll ausführen kann, für das eine Protokollbeschreibung 203 vorliegt. Das allgemeine Protokoll ist einfach folgendes:
- In einer sendenden Protokollvorrichtung Senden einer allgemeinen Protokollnachricht, die eine Protokollbeschreibung 203 enthält;
- in einer empfangenden allgemeinen Protokollvorrichtung, Verwenden eines Protokollanweisungsinterpretierers 209, um die in der allgemeinen Protokollnachricht enthaltene Protokollbeschreibung 203 auszuführen.
Fig. 3 zeigt eine solche allgemeine Protokollvorrichtung 301. Die allgemeine Protokollvorrichtung 301 enthält einen Protokollanweisungsinterpretiererspeicher (PIIM) 309, der eine Protokollbeschreibung 203 für das gerade von der Protokollvorrichtung 301 ausgeführte Protokoll und Protokollanweisungsinterpretiererdaten (PIIDATA) 311 enthält, die von dem Protokollanweisungsinterpretierer 209 bei der Ausführung der Protokollbeschreibung 203 verwendet werden. Der Protokollinterpretierer 209 besitzt zwei zusätzliche Komponenten: die bootstrap-Komponente (BOOT) 305 und die Fehlerkomponente (ERR) 307. Durch diese Komponenten wird es möglich, daß die allgemeine Protokollvorrichtung 301 das allgemeine Protokoll ausführt, und dadurch wird es möglich, daß eine beliebige Protokollvorrichtung 107, die eine Protokollbeschreibung 203 für die Protokollvorrichtung 301 bereitstellen kann, das Protokoll verwendet, das in der Protokollbeschreibung 203 beschrieben wird, um zwischen den Elementen 109 zu kommunizieren, zu denen die Protokollvorrichtung 107 und die Protokollvorrichtung 301 gehören. Natürlich können beide Protokollvorrichtungen, die an der Kommunikation beteiligt sind, allgemeine Protokollvorrichtungen 301 sein.
Die Protokollvorrichtung 301 führt das allgemeine Protokoll folgendermaßen aus: das Bootstrap 305 horcht nach einer allgemeinen Protokollnachricht (siehe Pfeil 313) von der anderen Protokollvorrichtung. Bei einer bevorzugten Ausführungsform verwendet die allgemeine Protokollnachricht denselben Weg zwischen den Protokollvorrichtungen wie die Protokolldaten 111. Bei anderen Ausführungsformen kann es einen speziellen Weg für die allgemeine Protokollnachricht geben. Die allgemeine Protokollnachricht enthält weiterhin mindestens den ersten Teil der Protokollbeschreibung 203 für das spezifische auszuführende Protokoll. Wenn das Bootstrap 305 die allgemeine Protokollnachricht empfängt, lädt es die Nachricht in einen Puffer in den Protokollanweisungsinterpretiererdaten 311 und führt nachfolgend beschriebene Prüfungen durch. Wenn die Nachricht die Prüfungen besteht, lädt das Bootstrap 305 die allgemeine Protokollnachricht in den Teil des Speichers 309, der für die Protokollbeschreibung 203 reserviert ist. Daraufhin beginnt der Interpretierer 209 mit der Ausführung der Protokollanweisungen 205 in der Nachricht, beginnend mit der Anfangsanweisung. Wenn die Protokollbeschreibung 203 länger als die maximale Größe einer allgemeinen Protokollnachricht ist, dann Enthält der erste Teil der Protokollbeschreibung 203 Protokollanweisungen, die bei der Ausführung bewirken, daß der Rest der Protokollbeschreibung 203 geladen wird.
Bei einer bevorzugten Ausführungsform erfordert das allgemeine Protokoll, daß die allgemeine Protokollnachricht Prüfinformationen, die eine Fehlerprüfung erlauben, und Protokolldateninformationen, die angeben, wie der Protokollanweisungsinterpretierer 209 die Protokolldaten 111 interpretieren soll, enthält, und daß die empfangende allgemeine Protokollvorrichtung 301 die Prüfinformationen und die Protokolldateninformationen verwendet. Bei der bevorzugten Ausführungsform gibt es zwei Partikel des Prüfens von Informationen: eine Prüfsumme für die allgemeine Protokollnachricht und eine erforderliche erste Anweisung. Beim Empfang der allgemeinen Protokollnachricht berechnet das Bootstrap 305 die Prüfsumme der allgemeinen Protokollnachricht und vergleicht sie mit der Prüfsumme in der Nachricht; wenn sie sich unterscheiden, ist ein Übertragungsfehler aufgetreten, und das Bootstrap 305 wartet auf eine weitere allgemeine Protokollnachricht. Wenn die Prüfung der erforderlichen ersten Anweisung in der allgemeinen Protokollnachricht durch das Bootstrap 305 anzeigt, daß die allgemeine Protokollnachricht keine Protokollbeschreibung 203 ist, gibt die Fehlerkomponente 307 des Protokollanweisungsinterpretierers 209 eine Fehlernachricht (siehe Pfeil 315) an die Protokollvorrichtung 101 zurück, die die allgemeine Protokollnachricht liefert. Daraufhin wartet der Fehler 307 auf eine gültige allgemeine Protokollnachricht. Wenn die allgemeine Protokollnachricht erfolgreich empfangen wurde, wird sie von dem Protokollanweisungsinterpretierer 209 ausgeführt, und als Teil der Ausführung werden die Protokolldateninformationen in der allgemeinen Protokollnachricht verwendet, um Parameterwerte in den Protokollanweisungsinterpretiererdaten 309 einzustellen.
Wenn beide Protokollvorrichtungen 107, die an einer Kommunikation beteiligt sind, Protokollvorrichtungen 301 sind, ist ein enormer Flexibilitätsgrad möglich. Wenn zum Beispiel ein Element 109, das eine Protokollvorrichtung 301 enthält, erfordert, daß zu ihm gesendete Informationen 105 gemäß einem gegebenen Protokoll gesendet werden, dann kann die Vorrichtung 301 auf ein allgemeines Protokoll reagieren, das ein anderes Protokoll angibt, indem sie eine Fehlernachricht zurückgibt, die anzeigt, daß sie nur auf ein gegebenes spezifisches Protokoll reagiert, und dann die Protokollbeschreibung 203 für das gegebene spezifische Protokoll zu dem Element sendet, von dem sie die allgemeine Protokollnachricht empfangen hat. Eine solche Taktik könnte von einem Element 109 verwendet werden, das erfordert, daß alle Daten, die es empfängt, gemäß einem bestimmten Schema verschlüsselt werden.
Wenn an einer Kommunikation zwischen zwei Elementen 109 verschiedene Arten von Daten beteiligt sind und es besser ist, zur Übermittlung von Daten, die zu den verschiedenen Typen gehören, verschiedene Protokolle zu verwenden, dann könnten in ähnlicher Weise zwei Protokollvorrichtungen 301 die Kommunikation ausführen, indem sie die Protokolle dynamisch so ändern, wie es von dem Typ der gerade übermittelten Daten erfordert wird. Ein Beispiel wäre hier ein Datentransfer, an dem sowohl digitale Daten, die Analogsignale darstellen, als auch digitale Daten, die Zahlen oder Zeichen darstellen, beteiligt sind. Die beiden Datentypen weisen verschiedene Toleranzgrade gegenüber Übertragungsfehlern auf und das für jeden Datentyp verwendete Protokoll könnte deshalb verschiedene Fehlerprüf- und Korrekturverfahren verwenden.

Adaptive allgemeine Protokollvorrichtung: Fig. 13

Die Flexibilität der allgemeinen Protokollvorrichtung 301 bringt Kosten mit sich: jede Übermittlung unter Verwendung eines spezifischen Protokolls enthält das Overhead des Sendens der Protokollbeschreibung 203 für das spezifische Protokoll zu der allgemeinen Protokollvorrichtung 301, das Prüfen der allgemeinen Protokollnachricht und das Laden der Protokollbeschreibung 203 in den Protokollanweisungsinterpretiererspeicher 309. Dieses Overhead läßt sich vermeiden, indem die allgemeine Protokollvorrichtung 301 mit einem Protokollanweisungsinterpretationsspeicher 1301 (Fig. 13) ausgestattet wird, der groß genug ist, um eine Anzahl der Protokollbeschreibungen 203 zu halten, und indem das allgemeine Protokoll so modifiziert wird, daß die Verwendung einer Protokollbeschreibungskennung zur Angabe einer der Protokollbeschreibungen anstelle einer Protokollbeschreibung 203 möglich wird. Bei einer solchen adaptiven allgemeinen Protokollvorrichtung wäre das allgemeine Protokoll wie folgt:
- In einer sendenden Protokollvorrichtung, Senden einer ersten Nachricht, die eine Protokollbeschreibungskennung für eine Protokollbeschreibung 203 enthält;
- in einer empfangenden Protokollvorrichtung, Reagieren auf die erste Nachricht durch:
a. Bestimmung, ob die empfangende allgemeine Protokollvorrichtung über eine Kopie der durch die Kennung angegebenen Protokollbeschreibung 203 verfügt;
b. wenn dies der Fall ist, Ausführung der durch die Kennung angegebenen Protokollbeschreibung 203;
c. wenn es nicht der Fall ist, Zurückgeben einer Fehlernachricht, die anzeigt, daß sie nicht über eine Kopie der angegebenen Protokollbeschreibung 203 verfügt;
- in der sendenden Protokollvorrichtung, Reagieren auf die Fehlernachricht durch Senden einer zweiten Nachricht, die die Protokollbeschreibung 203 enthält; und
- in der empfangenden Protokollvorrichtung, Reagieren auf die zweite Nachricht durch:
a. Speichern der Protokollbeschreibung 203 in der empfangenden Protokollvorrichtung; und
b. Ausführen der Protokollbeschreibung.
Wie aus der obigen Beschreibung des allgemeinen Protokolls für die adaptive allgemeine Protokollvorrichtung hervorgeht, würde sich eine solche allgemeine Protokollvorrichtung schnell an die Umgebung anpassen, in der sie verwendet wird. Sie würde kurzgefaßt Kopien der Protokollbeschreibungen 203 für alle Protokolle enthalten, die häufig von den Elementen 109 verwendet werden, die die adaptive allgemeine Protokollvorrichtung verwenden, und sie würde dementsprechend nur sehr selten eine Kopie einer Protokollbeschreibung 203 für ein Protokoll von dem Sender anfordern müssen. Anders ausgedrückt speichert eine adaptive allgemeine Protokollvorrichtung Protokollbeschreibungen 203 für häufig verwendete Protokolle genauso in einem Cache-Speicher wie ein Speichersystem häufig verwendete Speicherblöcke in einem Cache-Speicher speichert.
Eine adaptive allgemeine Protokollvorrichtung kann dadurch implementiert werden, daß das Bootstrap 303 und die Inhalte des Protokollanweisungsinterpretiererspeichers 301 modifiziert werden. Die Modifikationen der Inhalte des Protokollanweisungsinterpretiererspeichers für eine adaptive allgemeine Protokollvorrichtung 1323 sind in Fig. 13 gezeigt. Wie zuvor ist der Protokollanweisungsinterpretiererspeicher 1301 in zwei Teile aufgeteilt, wobei ein Teil Daten 311 enthält, die während der Ausführung eines Protokolls verwendet werden, und ein anderer Teil Protokollbeschreibungen. Hier enthält der Protokollbeschreibungsspeicher (PDM) 1302 eine Protokollbeschreibungstabelle 1303 und eine oder mehrere Protokollbeschreibungen 1311. Die Protokollbeschreibungstabelle 1303 enthält einen Protokollbeschreibungstabelleneintrag 1305 für jede Protokollbeschreibung 1311 im Speicher 1309. Jeder Eintrag 1305 enthält mindestens zwei Informationselemente: eine Kennung 1307 für eine Protokollbeschreibung 1311 und einen Zeiger 1309 auf die Speicherstelle im Speicher 1302 der Protokollbeschreibung 1311, die durch die Kennung angegeben wird. Es gibt viele mögliche Quellen der Kennungen; zum Beispiel kann die Kennung für eine gegebene Protokollbeschreibung 1311 die Prüfsumme der Beschreibung 1311 sein. Bei einer anderen Ausführungsform kann die Quelle der ursprünglichen Protokollbeschreibungen, von denen die Protokollbeschreibungen 1311 kopiert werden, jeder ursprünglichen Protokollbeschreibung eine eindeutige Kennung zuweisen.
Wie unten ausführlicher erläutert wird, definieren die Protokollbeschreibungen 203, die bei einer bevorzugten Ausführungsform verwendet werden, einen Automaten. Dementsprechend wird eine gegebene Protokollbeschreibung 203 in eine Menge numerierter Zustände (S) 1321 aufgeteilt. Damit die Zustände gefunden werden können, wird die Protokollbeschreibung 1311 in zwei Teile aufgeteilt: den Protokollbeschreibungskörper (PDB) 1314, der die Anweisungen für die Zustände enthält, und die Zustandstabelle 1313, die Zustandsnummern mit den Speicherstellen der entsprechenden Zustände 1321 in Bezug setzt. Es gibt einen Eintrag 1315 in der Zustandstabelle 1313 für jeden Zustand 1321 in dem Protokollbeschreibungskörper, und jeder Eintrag enthält die Zustandsnummer (SN) 1317 und das Offset. (OFF) 1319 dieses Zustands vom Beginn der Protokollbeschreibung 1311.
Die im Bootstrap 305 erforderlichen Modifikationen gehen unmittelbar aus Fig. 13 und der Beschreibung des allgemeinen Protokolls für die allgemeine Protokollvorrichtung 1323 hervor. Wenn eine allgemeine Protokollnachricht empfangen wird, die eine Protokollbeschreibungskennung enthält, für die sich die Protokollbeschreibung 1311 im Speicher 1302 befindet, bewirkt das Bootstrap 305 einfach, daß der Interpretierer 209 mit der Ausführung der angegebenen Protokollbeschreibung beginnt; andernfalls behält das Bootstrap 305 die Kennung aus der allgemeinen Protokollnachricht und bewirkt, daß der Fehler 307 eine Fehlernachricht zurückgibt und auf eine Nachricht wartet, die die Protokollbeschreibung 1311 enthält. Wenn die Nachricht ankommt, bewirkt der Fehler 307, daß das Bootstrap 305 die behaltene Kennung mit der Kennung in der allgemeinen Protokollnachricht vergleicht, die die Protokollbeschreibung 1311 enthält, und wenn sie übereinstimmen, bringt das Bootstrap 305 die Protokollbeschreibung 1311 in den Speicher 1302 und erstellt einen Eintrag 1305 für die neue Protokollbeschreibung 1311 in der Protokollbeschreibungstabelle 1303.
Es sind natürlich viele Abwandlungen der obigen Anordnungen möglich. Zum Beispiel ist der Speicher 1302 notwendigerweise endlich; folglich muß das Bootstrap 305 möglicherweise eine Protokollbeschreibung 1311 entfernen, um Platz für eine andere zu schaffen. Zu diesem Zweck könnte man zum Beispiel Größeninformationen und Informationen der letzten Benutzung in der Protokollbeschreibungstabelle 1303 hinzufügen, und das Bootstrap 305 könnte diese Informationen benutzen, um zu bestimmen, welche Protokollbeschreibungen 1311 entfernt werden sollten. Außerdem könnte das allgemeine Protokoll für die allgemeine Protokollvorrichtung 1323 eine Prüfsumme in der allgemeinen Protokollnachricht für die durch die Kennung identifizierte Protokollbeschreibung 1311 enthalten. Das Bootstrap 305 könnte die Prüfsumme verwenden, um sicherzustellen, daß die Kopie der Protokollbeschreibung 1311 im Speicher 1302 dieselbe wie die vom Sender gehaltene Kopie war. Wenn nicht, könnte das Bootstrap 305 eine Fehlernachricht senden, die die Protokollbeschreibung anfordert, und dann wie zuvor für die Protokollbeschreibungen, für die keine Kopie im Speicher 1302 vorliegt, beschrieben voranschreiten.

Implementierung der Protokollvorrichtung 301

Es wurde ein Prototyp der Implementierung der Protokollvorrichtung 301 aufgebaut, bei dem die Protokollausführungseinrichtung 207 ein Computer ist, der Programme ausführen kann, die in der wohlbekannten Programmiersprache "C" geschrieben sind. Bei dem Prototyp der Implementierung werden Protokollanweisungen 205, die zu einer Protokollbeschreibungssprache gehören, durch einen Protokollanweisungsinterpretierer interpretiert, der in C geschrieben ist und von einem auf dem Computer ablaufenden Prozeß ausgeführt wird. Die allgemeine Protokollvorrichtung 301 wurde geprüft, indem eine Protokollbeschreibung 203 für das Abwechslungsbitprotokoll in der Protokollbeschreibungssprache geschrieben wurde und das Protokoll durch Ausführen der Protokollbeschreibung 203 ausgeführt wurde. Die folgende Besprechung legt zunächst die Protokollbeschreibungssprache offen, dann den Protokollinterpretierer 209, das Bootstrap 305 und die Fehlerkomponente 307 und schließlich die Protokollbeschreibung 203 für das Abwechslungsbitprotokoll.

Die Protokollbeschreibungssprache: Fig. 4

Fig. 4 zeigt die Anweisungen bei einer bevorzugten Ausführungsform der Protokollbeschreibungssprache 401. Die Anweisungen fallen in zwei Klassen: Anweisungen, die allgemeines Stapel-Management und die Auswertung von Ausdrücken durchführen (siehe Tabelle 403) und Anweisungen, die Operationen durchführen, die insbesondere mit der Ausführung von Protokollen zusammenhängen (siehe Tabelle 405).
Wie aus Tabelle 403 ersichtlich ist, ist der Protokollanweisungsinterpretierer 209 eine Stapelmaschine. Der Stapel, der in den Protokollanweisungsinterpretationsdaten 311 gehalten wird, ist ein standardmäßiger push-down-Stapel mit ganzzahliger Größe. Die Anweisungen PUSH BYTE und PUSH WORD gestatten das Schieben von Daten auf den push-down-Stapel. Die anderen Anweisungen nehmen ihre Operanden und Parameter von der obersten Position des Stapels und schieben ihre Ergebnisse wieder zurück auf die oberste Position des Stapels. Wenn ein Stapelüberlauf oder -unterlauf auftritt, hört der Interpretierer 209 auf, das Protokoll auszuführen, die Fehlerkomponente 307 sendet eine Fehlernachricht zu der anderen Protokollvorrichtung 107 und die Fehlerkomponente 307 wartet dann auf eine Fehlerbehandlungsnachricht von der anderen Protokollvorrichtung 107. Wie die andere Protokollvorrichtung 107 auf die Fehlernachricht reagiert, ist natürlich Teil des in der Protokollbeschreibung 203 beschriebenen Protokolls. Dasselbe findet statt, wenn ein arithmetischer Fehler, wie zum Beispiel eine Division durch Null oder ein integer-Überlauf auftritt.
Die Funktionen der Anweisungen in der Tabelle 405 sind im allgemeinen aus der Tabelle klar; bestimmte Anweisungen müssen jedoch ausführlicher erläutert werden. Beginnend mit den Anweisungen in der Automatensteuerung 407 ermöglichen die Anweisungen 421 und 423 der Protokollbeschreibungssprache 401, ein Protokoll als einen Automaten zu beschreiben, d.h. als eine endliche Menge von Zuständen mit Definitionen von Übergängen zwischen den Zuständen. Somit nimmt die Anweisung LOAD 421 zwei Parameter von der obersten Position des Stapels, wobei einer einen Puffer angibt, der eine Folge von Anweisungen der Protokollbeschreibungssprache 401 enthält, und einer eine Zustandsnummer angibt. Die Anweisung LOAD lädt die Inhalte des Puffers in eine Speicherstelle in der Protokollbeschreibung 203 und ordnet dieser Speicherstelle die Zustandsnummer zu. Die Anweisung NXT 423 entnimmt der obersten Position des Stapels einen Zustandswert und beginnt mit der Ausführung der Folge von Anweisungen an der Speicherstelle in der Protokollbeschreibung 203, die dem Zustandswert zugeordnet ist. Die Anweisung IF 425 ist eine bedingte Verzweigungsanweisung: die Anweisung IF entnimmt den Wert auf der obersten Position des Stapels, und wenn der Wert auf der obersten Position des Stapels gleich 0 ist; verzweigt sich die Anweisung IF zu der Anweisung, die in dem Parameter der Anweisung IF angegeben ist; andernfalls führt sie die Anweisung nach der IF-Anweisung aus.
Die Anweisungen 409 der oberen Schnittstelle leiten Informationen 105 zu der Datenquelle bzw. dem -ziel 103 weiter und empfangen Informationen 105 aus der Datenquelle bzw. dem -ziel 103. Die Informationen werden aus Puffern in den Protokollanweisungsinterpretationsdaten 311 heraus und in diese hinein empfangen. Die Anweisungen 411 der unteren Schnittstelle befassen sich mit PDATA 111, die zwischen den Protokollvorrichtungen 107 gesendet und empfangen werden. Drei dieser Anweisungen werden beim Booten verwendet. CKSUM 413 berechnet die Prüfsumme der Inhalte eines Puffers und legt das Ergebnis in die oberste Position des Stapels, und dort können sie benutzt werden, um zu bestimmen, ob eine Verzweigung zu der Fehlerkomponente 307 erfolgen sollte. BYTEORDER definiert die Reihenfolge der Byte in den Wörtern von PDATA 111, die gemäß dem Protokoll gesendet werden. WORD_SZ definiert die Anzahl von Byte in den Wörtern von PDATA 111, die gemäß dem Protokoll gesendet werden. Beide Anweisungen werden in der allgemeinen Protökollnachricht verwendet, um Vorgabe- Bytereihenfolgen und -wortgrößen zu übersteuern und sie können außerdem zur Änderung dieser Aspekte von PDATA 111 während der Übertragung eines Protokolls verwendet werden. Die Puffermanagementanweisungen 419 teilen Puffer in PIIDATA 311 zu und bemessen sie und gestatten das Schreiben von Werten von der obersten Position des Stapels in Positionen in den Puffern. Für die meisten Anweisungen gibt es außerdem eine schnellere Variante (die durch das Präfix I angegeben wird), die konstante Operanden verwenden, die in der Anweisung angegeben werden, und deshalb keinen Operanden aus dem Stapel entnehmen müssen.
Es folgt ein kurzes beispielhaftes Programm, das in der Protokollbeschreibungssprache 401 geschrieben ist. Das Programm definiert die Bytereihenfolge und
- wortgröße für das Protokoll, lädt die Inhalte eines Puffers RBUF in die Protokollbeschreibung 203 und ordnet der Speicherstelle der geladenen Inhalte eine als S dargestellte Zustandsnummer zu und beginnt dann mit der Ausführung der Inhalte als Zustand S.
S ist ein konstanter Wert, wie auch RBUF, so daß I_LOAD und I_NXT anstelle von LOAD und NXT in dem Programm verwendet werden.
Obwohl die Protokollbeschreibungssprache 401 Protokolle effektiv beschreibt, würde eine Person, die ein beträchtliches Protokoll implementiert, die Protokollbeschreibung nicht direkt in der Sprache 401 schreiben wollen. Um dieses Problem zu vermeiden, kann die das Protokoll implementierende Person das Protokoll in einer beliebigen formalen Protokollspezifikationssprache beschreiben, die in die Sprache 401 übersetzt werden kann, und dann die Beschreibung in der formalen Spezifikationssprache in die Sprache 401 übersetzen. Sogar eine normale Programmiersprache würde zur Beschreibung des Protokolls ausreichen. Wenn das Protokoll in einer formalen Proto- kollspezifikationssprache spezifiziert wird, die die Validierung des Protokolls gestattet (siehe zum Beispiel die Spezifikationssprache PROMELA in Holzmann, supra, S. 9lff.), dann gibt es den zusätzlichen Vorteil, daß das vollständige Protokoll erschöpfend validiert werden kann, bevor es in die Protokollbeschreibungssprache 401 umgewandelt wird. In diesem Fall ist es sicher, daß beide Seiten des Protokolls präzise gemäß dem validierten Modell implementiert werden.

Protokollanweisungsinterpretierer 209

Bei einer bevorzugten Ausführungsform wird der Protokollanweisungsinterpretierer 209 mittels einer Prozedur run implementiert, die später ausführlicher erläutert wird. Im Zentrum dieser Prozedur liegt die Prozedur transition (n). Ein Fragement von transition (n) ist in Fig. 10 gezeigt. transition(n) 1001 führt die Protokollanweisungen 205 in einem Zustand aus, bis eine NXT- oder I_NXT-Anweisung die Steuerung an einen anderen Zustand weitergibt. Die Prozedur wird mit einem einzigen Argument aufgerufen: der Nummer des Zustands, zu dem der Übergang erfolgen soll; wenn die Prozedur zurückkehrt, gibt sie die Nummer des nächsten Zustands zurück, zu dem ein Übergang erfolgen soll. Die Variable cur_state wird beim Eintritt in die Prozedur so gesetzt, daß sie auf den Anfang des durch das Argument angegebenen Zustands zeigt. Die Registervariable prot enthält die aktuelle Byteposition in dem Zustand, der ausgeführt wird. Bei 1006 wird prot auf einen Wert von cur_state gesetzt, so daß die Ausführung mit dem ersten Byte des Zustands beginnt. Die bei 1007 angegebene while-Schleife wird weiter ausgeführt, solange prot einen von 0 verschiedenen Wert aufweist, d.h. im wesentlichen bis eine return-Anweisung die Steuerung aus transition heraus führt.
Der Hauptteil der while-Schleife ist ein switch-Befehl, der einen Fall für jede Anweisung in der Protokollbeschreibungssprache 401 enthält. Bei jeder Iteration der Schleife wird die Variable prot um 1 erhöht, so daß sie auf das nächste Byte in dem Zustand zeigt. Der Wert dieses Byte bestimmt, welcher Fall ausgeführt wird. Wenn kein Fall vorliegt, der diesem Wert entspricht, wird der Vorgabefall 1015 ausgeführt, der den Interpretierer 209 in den Fehlerzustand versetzt und dadurch die Steuerung an Fehler 307 abgibt. Falls erforderlich, enthält ein Fall weiterhin debug-Codes und logische Zustände, um zu prüfen, ob die Anforderungen für die Ausführung der Anweisung erfüllt sind. Wenn der Interpretierer 209 nur mit voll geprüften und verifizierten Protokollbeschreibungen 203 verwendet wird, können die logischen Zustände und der debug-Code deaktiviert werden.
Das Fragment 1001 zeigt neben dem Vorgabefall 1015 zwei Fälle: die Fälle für NXT und I_NXT. Bei NXT 1011 entnimmt der Fall einfach nur den Wert an der obersten Position des Stapels (d.h. den nächsten Zustand), prüft, ob der Wert in dem Wertebereich für Zustände liegt, und gibt den Wert zurück. Bei I_NXT ist der Wert des nächsten Zustands in dem Code und nicht auf dem Stapel, so daß der Fall prot um eins erhöht, prüft, ob der Wert an diesem Punkt in dem Code in dem Bereich liegt, und gibt den Wert zurück.

Implementierung von Bootstrap 305: Fig. 5

Bei einer bevorzugten Ausführungsform wird Bootstrap 305 als ein Zustand des Interpretierers 209 implementiert. Im Gegensatz zu den anderen Zuständen, die durch die Protokollbeschreibung definiert werden, die durch Bootstrap 305 hereingeladen werden, sind Bootstrap 305 und Fehler 307 für die Ausführung des allgemeinen Protokolls erforderlich und müssen deshalb in eine Protokollvorrichtung 301 eingebaut werden, bevor eine Protokollbeschreibung 203 geladen werden kann.
Da diese beiden Zustände für das allgemeine Protokoll erforderlich sind, sind sie die einzigen, die bei ankommenden Nachrichten ein vordefiniertes Format erzwingen, und dies muß das Vorliegen bestimmter Arten von Daten erfordern, um eine Prüfung der allgemeinen Protokollnachricht zu ermöglichen. Sobald diese beiden Zustände erfolgreich eine allgemeine Protokollnachricht mit der Protokollbeschreibung 203 empfangen haben, geben sie die Steuerung der allgemeinen Protokollvorrichtung an die Protokollbeschreibung 203 ab.
Bei einer bevorzugten Ausführungsform wird Bootstrap 305 mit einem einzigen Aufruf run(BOOTSTRAP) implementiert. Die Prozedur run() ist bei einer bevorzugten Ausführungsform die Implementierung des Interpretierers 209. Die Prozedur wird unten vollständig wiedergegeben.
run(s)
{ int n = s; while (n > = 0 && n < = SMAX && State[n].cont)
n = transition(n);
return n; }
run ist eine Schleife, die die Prozedur transition mit einer Zustandsnummer aufruft. transition versetzt den Interpretierer 209 dann in den ordnungsgemäßen Zustand der Protokollbeschreibung 203 bzw. die Zustände, die Bootstrap 305 oder Fehler 307 implementieren. Die Ausführung der Schleife endet, wenn ein Wert, der außerhalb des Umfangs legaler Zustandsnummern liegt, empfangen wird. Beim Aufruf mit BOOTSTRAP, einer Konstante, die den bootstrap-Zustand anzeigt, versetzt das run somit einfach den Interpretierer 209 in den bootstrap-Zustand.
Die meisten Konzepte bei der Implementierung Einer Ausführungsform der Protokollvorrichtung 301 können mit einer Implementierung des Bootstrap 305 veranschaulicht werden. In einer Protokollvorrichtung 301, die eine solche Implementierung verwendet, wäre der Code für Bootstrap 305 immer in dem Protokollanweisungsinterpretiererspeicher 309 anwesend.
Für ein allgemeines Verständnis des Bootstrap 305 genügt das Flußdiagramm von Fig. 5. Wie im Oval 503 gezeigt, wartet die bootstrap-Implementierung 501 auf die allgemeine Protokollnachricht aus der fernen Protokollvorrichtung 107. Wenn die Nachricht ankommt, wird sie in einen Puffer in den Protokollanweisungsinterpretiererdaten 311 geladen. Als nächstes wird die Nachricht geprüft. Als erstes wird eine Prüfsumme durchgeführt, um sicherzustellen, daß die Nachricht unverfälscht ist. Wenn die Prüfsumme von Null verschieden ist, ist ein Übertragungsfehler aufgetreten, und die Maschine kehrt zum Start des bootstrap-Zustands (Raute 505, 507) zurück. Wenn die Prüfsumme Null ist, wird geprüft, ob die Nachricht den korrekten Typ aufweist (Raute 509). Bei einer bevorzugten Ausführungsform muß die erste Anweisung die Definition von BYTEORDER für die untere Schnittstelle sein. Diese Bytereihenfolgedefinition gibt die Reihenfolge an, in der die Byte in einem Wort, das gemäß dem Protokoll gesendet wird, über die Schnittstelle der niedrigen Ebene gesendet werden: zuerst das höchstwertige oder zuerst das niedrigstwertige Byte. Sie muß nicht mit der Bytereihenfolge übereinstimmen, die in dem empfangenden der sendenden Element verwendet wird. Wenn die Nachricht keine gültige Protokollbeschreibung 203 ist, tritt der Interpretierer 209 in Fehler 307 ein (511). Wenn die Nachricht eine gültige Protokollbeschreibung 203 ist, werden die Inhalte des Empfangspuffers dem Anfangszustand des neu geladenen Protokolls zugewiesen und die Steuerung wird an diesen Zustand abgegeben (Kasten 515). Eine volle Implementierung 1101 von Bootstrap 305 in der Protokollbeschreibungssprache 401 ist in Fig. 11 gezeigt.

Implementierung von Fehler 307: Fig. 6

Bei einer bevorzugten Ausführungsform wird die Fehlerkomponente 307 ebenfalls als ein Zustand des Interpretierers 209 implementiert. Wie der bootstrap- Zustand ist dieser Fehlerzustand Teil des allgemeinen Protokolls, und keines spezifischen Protokolls. Er soll lediglich einen standardmäßigen Mechanismus für Reaktionen auf Fehler beim Betrieb der allgemeinen Protokollvorrichtung 301, wie zum Beispiel bei Stapelüberlauf, Speicherzuteilungsfehlern, arithmetischen Fehlern (z.B. Division durch Null) usw. bereitstellen.
Ein Flußdiagramm für den Fehlerzustand ist in Fig. 6 angegeben.
Wie in Fig. 6 gezeigt, schreibt die Fehlerkomponentenimplementierung 601 zunächst eine vordefinierte Fehlernachricht in TBUF (Kasten 603) und benachrichtigt dann die ferne Protokollvorrichtung 107 über einen Fehlerzustand, indem sie die Nachricht in TBUF s endet (Oval 605). Sie wartet dann auf eine Antwort, die sie in dem Vorgabe-Empfangspuffer RBUF empfängt (Oval 607). Wenn die Nachricht unverfälscht war (Raute 609) und eine Protokollbeschreibung 203 war (Raute 613), wird die Steuerung mit dem Befehl NXT (617) an den Zustand abgegeben, der in der Nachricht angegeben ist. In allen anderen Fällen (611, 615) erfolgt ein erneuter Eintritt in den Fehlerzustand von der obersten Position (602). Eine volle Implementierung 1201 von Fehler 307 in der Protokollbeschreibungssprache 401 ist in Fig. 12 gezeigt.

Eine Implementierung des Abwechslungsbitprotokolls: Fig. 7-10

Fig. 7 ist ein Diagramm von Automaten, die durch zwei Protokollvorrichtungen 107 implementiert werden, die mittels des Abwechslungsbitprotokolls kommunizieren. Dieses Protokoll verwendet ein einziges Bit, das den Wert "1" oder "0" aufweisen kann, als eine Nachrichtensequenznummer. Wenn eine der Vorrichtungen 107, z.B. die Vorrichtung, die durch den Automaten 703 dargestellt wird, eine Nachricht sendet, hängt sie ein "1" oder ein "0" Bit als eine Sequenznummer an die Nachricht an. Der empfangende Automat 705 sendet eine Bestätigung mit der Sequenznummer, die er empfangen hat, zu dem sendenden Automaten 705; wenn die Sequenznummer der Bestätigung mit der Sequenznummer der gesendeten Nachricht übereinstimmt, kann der sendende Automat eine weitere Nachricht mit der anderen Sequenznummer senden; andernfalls wiederholt er die zuletzt gesendete Nachricht.
In Fig. 7 geben Kreise Zustände an, und die Ränder geben Zustandsübergänge an, die sich aus Nachrichtenaustauschvorgängen ergeben. Die Randetiketten geben die Nachrichtenaustauschvorgänge an. Jedes Etikett besteht aus zwei Zeichen: A zeigt an, daß die Nachricht aus dem Automaten 703 kommt; B zeigt an, daß sie aus dem Automaten 705 kommt. Das zweite Zeichen gibt wie oben beschrieben die Sequenznummer 1 oder 0 an. Wenn ein Randetikett unterstrichen ist, zeigt es an, daß die Nachricht zu dem anderen Automaten gesendet wird. Die Pfeile mit zwei Spitzen zeigen Zustände an, in denen der Empfänger eine Nachricht von dem Sender annehmen kann oder der Sender eine neue Nachricht zur Ausgabe zum Empfänger abholen kann.
Ausführlicher empfängt im Zustand 707 der Sender 703 eine Nachricht A, die an den Empfänger 705 ausgegeben werden soll. Er hängt die Sequenznummer "0" an und gibt die Nachricht aus. Im Zustand 709 wartet er auf die Bestätigung, die als Nachricht B angegeben ist. Wenn B die Sequenznummer "0" aufweist, ist der nächste Zustand 711, wobei eine neue Nachricht A zur Ausgabe empfangen wird und die Sequenznummer "1" angehängt wird. Im Zustand 713 wartet der Sender 703 auf die Bestätigung, die wiederum als B bezeichnet wird; wenn die Nachricht die Sequenznummer "1" trägt, beginnt der Zyklus erneut im Zustand 707. Wenn die im Zustand 709 empfangene Bestätigung die Sequenznummer "1" trägt, ist der nächste Zustand 715, der die Nachricht A, die in 707 gesendet wurde, mit der Sequenznummer "0" neu sendet. Wenn dieses Mal die richtige Bestätigung empfangen wird, ist der nächste Zustand 711; andernfalls erfolgt ein Neueintritt in den Zustand 715. Wenn eine A-Nachricht mit einer Sequenznummer "1" eine Bestätigung mit einer Sequenznummer "0" empfängt, geht der Sender 703 ähnlich zu dem Zustand 717 über, in dem er die A1-Nachricht neu sendet.
Fig. 8 zeigt, wie der Teil des Abwechslungsbitprotokolls, der empfangenen Nachrichten antwortet, mit der Protokollbeschreibungssprache 401 implementiert wird. Der Code 801 für den Empfangsteil des Protokolls hat drei Teile: im Teil 803 werden die Puffer für den Sende- und für den Empfangsteil definiert; für den Empfangsteil sind nur drei Puffer erforderlich: ein Sendepuffer TBUF, ein Empfangspuffer RBUF und eine Variable VAR_E für die erwartete Sequenznummer.
Der Teil 805 ist der Zustand 0 des Teils des Automaten, der Nachrichten empfängt. Die Protokollanweisungen 205 des Zustands 0 werden in der allgemeinen Protokollnachricht empfangen und dann ausgeführt, wenn Bootstrap 305 die Steuerung an den Zustand 0 abgibt. Wie bei der bevorzugten Ausführungsform gefordert wird, ist die erste Anweisung eine BYTEORDER-Anweisung, die hier angibt, daß das erste Byte der gemäß dem Protokoll empfangenen Wörter das höchstwertige Byte ist. Die Anweisungen in den Byte 2 bis 10 der allgemeinen Protokollnachricht teilen Pufferraum für TBUF und VAR_E zu. Die Anweisungen in den Byte 11 bis 17 geben an, daß der Empfänger auf die nächste Nachricht warten soll, die die Protokollanweisungen 205 des Zustands 1 enthält, diese Nachricht in RBUF legen soll, die Inhalte von RBUF in den Teil des Speichers 309 laden soll, der für die Protokollbeschreibung 203 reserviert ist, und den Zustand 1 der Speicherstelle der geladenen Inhalte im Speicher 309 zuordnen und dann den Zustand 1 ausführen soll. Der Abschnitt des Teils 805, der mit Byte 18 beginnt, ist für die Prüfsumme reserviert, die Bootstrap 305 zur Prüfung auf Korrektheit der Übertragung verwendet.
Der Abschnitt 807 ist der Zustand 1 des Teils des Automaten, der Nachrichten empfängt. In diesem Zustand wartet der Automat auf eine Nachricht (Byte 0). Wenn die Nachricht ankommt, wird sie in RBUF gelegt. In den Byte 2 bis 12 schreibt der Automat einen Wert, der eine Bestätigung angibt (in diesem Fall das Zeichen 'A') in den Sendepuffer, bestimmt die Sequenznummer in dem letzten Byte von RBUF, kopiert die Sequenznummer nach dem 'A' in TBUF und sendet die Bestätigung. In den Byte 14 bis 20 vergleicht der Automat den Wert der in VAR_E gehaltenen Sequenznummer mit der Sequenznummer in dem letzten Byte von RBUF. Wenn sie übereinstimmen, was bedeutet, daß die empfangene Nachricht die richtige Sequenznummer aufwies, werden die Byte 23 bis 33 ausgeführt; andernfalls wird Zustand 1 nochmals von Anfang an ausgeführt (siehe Byte 34). In den Byte 23 bis 31 wird die in VAR_E gesicherte Sequenznummer von 1 subtrahiert und das Ergebnis wieder in VAR_E gesichert. Danach wird die Nachricht zu ihrem Ziel gesendet und der Zustand 1 erneut von Anfang an ausgeführt.
Fig. 9 zeigt, wie der Abschnitt des Abwechslungsbitprotokolls, der Nachrichten sendet, bei einer bevorzugten Ausführungsform implementiert wird. Bei der bevorzugten Ausführungsform ist die Protokollvorrichtung 107, in der der Sendeteil 901 implementiert wird, eine Protokollvorrichtung 201 oder 301, die zu einer Protokollvorrichtung 301 sendet. Folglich wird der Sendeteil in der Protokollbeschreibungssprache 401 implementiert und enthält Anweisungen, die den Empfangsteil 801 in die empfangende Protokollvorrichtung 301 herunterlädt.
Die im Teil 901 verwendeten Puffer und Variablen werden im Teil 803 von Fig. 8 definiert. In dem Prototyp werden die Puffer 0 und 1 im voraus gesetzt, so daß sie jeweils eine Nachricht enthalten; wie aus Teil 809 von Fig. 8 hervorgeht, wird der Puffer 0 (namens M0) auf das ASCII-Zeichen 'M' gesetzt, woran die Sequenznummer "0" angehängt wird, während der Puffer 1 auf das ASCII-Zeichen 'M' gesetzt wird, woran die Sequenznummer "1" angehängt wird. Der Puffer R_run enthält den Code des Teils 807, während der Puffer R_ini den Code des Teils 805 enthält. Schließlich wird der Puffer R_ack für die Bestätigung verwendet, die aus dem Empfänger 801 empfangen wird. Es gibt zwei Variablen: VARS, die eine Sequenznummer hält, die an die Nachricht angehängt werden soll, und VAR_CNT, die einen. Zählwert der vom Sender gesendeten Byte darstellt.
Wieder mit Bezug auf Fig. 9 findet die Zuteilung und Initialisierung der Senderpuffer und -variablen, die in 803 definiert werden, im Abschnitt 903 statt, d.h. im Zustand 0. Die Byte 0-13, VAR_S und VAR_CNT werden ebenfalls zugeteilt und auf O gesetzt; in den Byte 14 und 15 wird Empfängerinitialisierungscode 805, der in dem Puffer R_im enthalten ist, zum Empfänger gesendet; in den Byte 16 und 17 wird der Code 807 für den Zustand 1 des Empfängers, der in dem Puffer R_run enthalten ist, zum Empfänger gesendet. Diese Zeilen 905 führen somit das Herunterladen der Protokollbeschreibung 203 in die empfangende Protokollvorrichtung 301 durch. Im Byte 18 beginnt schließlich die Anweisung I_NXT mit der Ausführung des Zustands 1 907.
In den Byte 0-2 des Zustands 1 907 wird der aktuelle Wert von VAR_S auf den Stapel geschoben. Im Byte 3 nimmt SEND seinen Parameter von der obersten Position des Stapels; wenn VAR_5 den Wert 0 aufweist, wird somit die Nachricht in dem Puffer M0 gesendet; wenn sie den Wert 1 aufweist, wird die Nachricht im Puffer M1 gesendet. Bei einer Ausführungsform zur Verwendung in einem tatsächlichen Kommunikationssystem würde es vor der SEND-Anweisung Code geben, der die Anweisung OBTATN verwenden würde, um ein zu sendendes Datenbyte abzurufen und die Daten abhängig von dem Wert von VAR_S in dem Puffer M0 oder M1 abzulegen, und dann CPY_BYTE verwenden würde, um, wiederum abhängig von dem Wert von VAR_S. "0" oder "1" an die Daten anzuhängen.
Der Code in den Byte 4-8 empfängt die Bestätigung aus dem Empfänger und schiebt sie wieder auf den Stapel. Wie bei der Besprechung des Empfängers erwähnt wurde, hat die Bestätigung die Form 'A'< sequence_number> . Das oberste Byte des Stapels sollte folglich 'A' enthalten, und das nächste Byte sollte die Sequenznummer enthalten. In den Byte 9-11 wird das oberste Byte geprüft, um zu sehen, ob es 'A' enthält. Wenn dies der Fall ist, werden die Byte 14-31 ausgeführt; andernfalls wird die Ausführung mit Byte 32 fortgesetzt. Die Byte 14-31 prüfen, ob die Bestätigung die richtige Sequenznummer aufweist; wenn dies der Fall ist, setzen sie VAR_S auf die nächste Sequenznummer. Genauer gesagt prüfen die Byte 14-20, ob die Sequenznummer in der Bestätigung mit dem Wert von VAR_S übereinstimmt. Wenn nicht, wird die Ausführung mit dem Byte 32 fortgesetzt; wenn ja, wird VAR_S auf seinen neuen Wert gesetzt, indem sein aktueller Wert von 1 subtrahiert wird (Byte 23-31).
Der Code in den Byte 32-54 akaualisiert VAR_CNT und beendet den Zustand 1, wenn die Anzahl von Nachrichten größer als die Konstante NR_MSGS ist, die in 803 als 32765 definiert ist. In den Byte 32-40 wird 1 zu dem aktuellen Wert von VAR_CNT addiert. In den Byte 41-47 wird VAR_CNT auf den Stapel geschoben, die höchstwertigen und niedrigstwertigen Byte von NR_MSGS werden auf den Stapel geschoben und die beiden Werte werden verglichen. Wenn VAR_CNT> = NR_MSGS gilt, legen die Byte 50-52 den Wert -1 auf den Stapel. NXT gibt den Wert an run zurück, das daraufhin, wie ber5eits erläutert, endet. Andernfalls wird das Byte 54 ausgeführt, das bewirkt, daß der Zustand 1 907 wieder mit der Ausführung beginnt.

Leistung der Protokollvorrichtung 201 oder 301

Die Leistung der Implementierung des gerade beschriebenen Abwechslungsbitprotokolls wurde mit der Leistung einer Implementierung verglichen, bei der der Sender und der Empfänger einfach in der Programmiersprache "C" codiert wurden. Das durch die Verwendung der Protokollbeschreibung 203 und des Interpretierers 209 anstelle eines "C"-Programms verursachte Overhead lag im Bereich von 10-30%, abhängig von der Länge der gesendeten Nachricht (längere Nachrichten weisen ein kleineres Overhead auf). Bei vielen Anwendungen wird das zusätzliche Overhead durch den Umstand ausgeglichen, daß die Protokollvorrichtung der Erfindung ein beliebiges Protokoll interpretieren kann, für das es eine Protokollbeschreibung 203 gibt. Außerdem gibt es viele Verfahren zur Reduktion des Overhead. Das vielversprechendste Verfahren ist wahrscheinlich, den Interpretierer 209 in Hardware zu implementieren; solche Hardware wäre in der Lage, ein beliebiges Protokoll auszuführen, für die eine Protokollbeschreibung 203 existiert. Zu anderen Optimierungen gehört die Implementierung des Interpretierers 209 dergestalt, daß eine minimale Anzahl von Prozeduraufrufen erforderlich ist, wodurch die Protokollbeschreibungen 203 optimiert werden, um Stapeloperationen zu vermeiden, und indem der Interpretierer 209 als ein laufender Compiler implementiert wird, d.h. der Interpretierer 209 arbeitet durch Empfangen der Protokollbeschreibung 203 und Compilierung der Protokollbeschreibung 203 zu Maschinenanweisungen für die Hardware, die das Protokoll eigentlich implementiert. Wenn die Protokollvorrichtung adaptiv ist, müßte die Compilierung nur vor der ersten Ausführung der Protokollbeschreibung durchgeführt werden, nachdem sie in die Protokollvorrichtung geladen wurde.

Schlußfolgerung

In der obigen ausführlichen Beschreibung wurde Durchschnittsfachleuten offengelegt, wie eine Protokollvorrichtung aufgebaut werden kann, die in der Lage ist, ein beliebiges Protokoll auszuführen, für das eine Protokollbeschreibung in einer gegebenen Protokollsprache geschrieben wurde, wie eine sendende Protokollvorrichtung eine Protokollbeschreibung einer empfangenden Protokollvorrichtung zuführen kann und dadurch die Ausführung eines beliebigen Protokolls durch die empfangende Protokollvorrichtung bereitstellen kann, und wie eine empfangende Protokollvorrichtung aufgebaut werden kann, die sich automatisch an die Umgebung anpaßt, in der sie verwendet wird. Zu den Vorteilen der hier offengelegten Techniken gehören präzisere Implementierungen von Protokollen, reduzierte Implementierungskosten und eine stark vergrößerte Flexibilität.
Obwohl hier eine beispielhafte Protokollbeschreibungssprache und eine beispielhafte Implementierung eines Interpretierers für diese Protokollbeschreibungssprache offengelegt wurden, ist für Durchschnittsfachleute erkennbar, daß andere Protokollbeschreibungssprachen und andere Implementierungen des Interpretierers möglich sind. Außerdem können andere Anordnungen zum Herunterladen oder anderweitigen Spezifizieren von Protokollbeschreibungen als die hier offengelegten verwendet werden.

Claims

1. Kommunikationsverfahren in einem verteilten System, das die folgenden Schritte umfaßt:

in einem ersten Bestandteil (201) des verteilten Systems, Empfangen einer ersten allgemeinen Protokollnachricht, die eine Protokollbeschreibung (203) enthält, die ein spezifisches Protokoll beschreibt, dadurch gekennzeichnet, daß

das durch die Protokollbeschreibung beschriebene spezifische Protokoll dem ersten Bestandteil zuerst unbekannt ist, wobei die Protokollbeschreibung in einer Protokollbeschreibungssprache vorliegt, die von jeder konkreten Hardware- oder Softwareimplementierung des ersten Bestandteils unabhängig ist; und

auf die erste allgemeine Protokollnachricht reagiert wird, indem ein erstes Protokollbeschreibungsinterpretationsmittel (209) verwendet wird, um die in der ersten allgemeinen Nachricht enthaltene Protokollbeschreibung auszuführen, wodurch der erste Bestandteil unter Verwendung des spezifischen Protokolls mit einem zweiten Bestandteil des verteilten Systems kommunizieren kann.

2. Kommunikationsverfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet, daß der Schritt des Reagierens auf die erste allgemeine Protokollnachricht den Schritt des Prüfens der ersten allgemeinen Protokollnachricht umfaßt.

3. Kommunikationsverfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet, daß der Schritt des Reagierens auf die erste allgemeine Protokollnachricht den Schritt des Interpretierens von Protokolldaten umfaßt, die gemäß dem spezifischen Protokoll gemäß einem in der ersten allgemeinen Protokollnachricht enthaltenen Parameter übermittelt werden.

4. Kommunikationsverfahren nach Anspruch 3, weiterhin dadurch gekennzeichnet, daß

der Parameter die in den Protokolldaten verwendete Byte-Reihenfolge angibt; und

der Schritt des Interpretierens von Protokolldaten die Protokolldaten gemäß der in dem Parameter angegebenen Byte-Reihenfolge interpretiert.

5. Kommunikationsverfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet, daß

der Parameter die in den Protokolldaten verwendete Wortgröße angibt; und

der Schritt des Interpretierens von Protokolldaten die Protokolldaten gemäß der in den Protokolldaten verwendeten angegebenen Wortgröße interpretiert.

6. Kommunikationsverfahren nach Anspruch 1, weiterhin dadurch gekennzeichnet, daß

in einer zweiten Protokollvorrichtung die erste allgemeine Protokollnachricht von der zweiten Protokollvorrichtung zu der ersten Protokollvorrichtung gesendet wird; und

das angegebene Protokoll zur Kommunikation mit der ersten Protokollvorrichtung verwendet wird.

7. Verfahren nach Anspruch 6, weiterhin dadurch gekennzeichnet, daß

in dem ersten Bestandteil

eine zweite allgemeine Protokollnachricht empfangen wird, die eine Protokollkennung enthält, die die Protokollbeschreibung angibt;

auf die zweite allgemeine Protokollnachricht reagiert wird, indem bestimmt wird, ob die angegebene Protokollbeschreibung dem ersten Bestandteil zugänglich ist;

wenn die angegebene Protokollbeschreibung zugänglich ist, das erste Protokollbeschreibungsinterpretationsmittel verwendet wird, um die angegebene Protokollbeschreibung zu interpretieren; aber

wenn die angegebene Protokollbeschreibung nicht zugänglich ist, eine erste Fehlernachricht gesendet und daraufhin der Schritt des Empfangens der ersten allgemeinen Protokollnachricht durchgeführt wird.

8. Protokollvorrichtung in einem ersten Element eines verteilten Systems zur Kommunikation mit anderen Elementen des verteilten Systems, wobei die Protokollvorrichtung durch folgendes gekennzeichnet ist:

ein Mittel zum Empfangen (207) einer ersten allgemeinen Protokollnachricht, die ein beliebiges Datenkommunikationsprotokoll definiert, das dem ersten Bestandteil zuerst unbekannt ist, wobei das beliebige Datenkommunikationsprotokoll in einer Protokollbeschreibungssprache definiert ist, die von jeder konkreten Hardware- oder Softwareimplementierung des ersten Elements unabhängig ist; und

ein Mittel zum Konfigurieren (209) des ersten. Elements, so daß es Daten empfängt, die in einem beliebigen Datenkommunikationsprotokoll formatiert sind.

9. Protokollvorrichtung nach Anspruch 8, wobei das Mittel zum Empfangen einer ersten allgemeinen Protokollnachricht die erste allgemeine Protokollnachricht prüft, um zu bestimmen, ob die erste allgemeine Protokollnachricht korrekt übertragen wurde; und

das Mittel zum Konfigurieren des ersten Elements das erste Element nicht so konfiguriert, daß es Daten empfängt, die in dem beliebigen Datenkommunikationsprotokoll formatiert sind, wenn die erste allgemeine Protokollnachricht nicht korrekt übertragen wurde.

10. Protokollvorrichtung nach Anspruch 8, wobei das Mittel zum Empfangen einer ersten allgemeinen Protokollnachricht ein Prüf- und Anzeigemittel zum Prüfen der ersten allgemeinen Protokollnachricht und zum Anzeigen, ob die erste allgemeine Protokollnachricht eine gültige erste allgemeine Protokollnachricht ist, enthält, wobei die Protokollvorrichtung weiterhin ein Fehlerbehandlungsmittel zum Senden einer Fehlernachricht, wenn das Prüf- und Anzeigemittel anzeigt, daß die erste allgemeine Protokollnachricht nicht gültig ist, enthält.

11. Protokollvorrichtung nach Anspruch 8, weiterhin umfassend: ein Fehlerbehandlungsmittel zum Senden einer Fehlernachricht, wenn während des Betriebs des Mittels zum Konfigurieren des ersten Elements, so daß es Daten empfängt, die in dem beliebigen Datenkommunikationsprotokoll formatiert sind, ein Fehler auftritt.

12. Protokollvorrichtung nach Anspruch 11, wobei die erste Datennachricht mindestens einen Parameter zum Interpretieren von gemäß dem beliebigen Datenkommunikationsprotokoll übermittelten Daten enthält; und das Mittel zum Konfigurieren des ersten Elements die übertragenen Daten gemäß dem mindestens einen Parameter interpretiert.

13. Protokollvorrichtung nach Anspruch 12, wobei der mindestens eine Parameter eine Byte- Reihenfolge der übertragenen Daten angibt; und das Mittel zum Konfigurieren des ersten Elements die übertragenen Daten auf der Grundlage der angegebenen Byte-Reihenfolge interpretiert.

14. Protokollvorrichtung nach Anspruch 12, wobei der mindestens eine Parameter eine Wortgröße der übertragenen Daten angibt; und das Mittel zum Konfigurieren des ersten Elements die übertragenen Daten auf der Grundlage der angegebenen Wortgröße interpretiert.

15. Protokollvorrichtung nach Anspruch 14, wobei das Mittel zum Konfigurieren des ersten Elements die ersten Daten durch direktes Ausführen von in der ersten allgemeinen Protokollnachricht enthaltenen Anweisungen interpretiert.

16. Protokollvorrichtung nach Anspruch 9, wobei das Mittel zum Konfigurieren des ersten Elements die erste allgemeine Protokollnachricht durch Kompilieren der ersten allgemeinen Protokollnachricht zur Erzeugung von Anweisungen interpretiert.

17. Vorrichtung zur Kommunikation zwischen Computern in einem verteilten System, umfassend:

eine erste Datenverarbeitungsvorrichtung des verteilten Systems, die so konfiguriert ist, das sie ein Datenkommunikationsprotokoll verwendet;

eine zweite Daterverarbeitungsvorrichtung des verteilten Systems, die so konfiguriert ist, das sie ein beliebiges Datenkommunikationsprotokoll verwendet;

dadurch gekennzeichnet, daß die erste Datenverarbeitungsvorrichtung folgendes enthält:

ein Empfangsmittel (207) zum Empfangen einer allgemeinen Protokollnachricht von der zweiten Datenverarbeitungsvorrichtung, die das beliebige Datenkommunikationsprotokoll definiert, das der ersten Datenverarbeitungsvorrichtung zuerst unbekannt ist, und die in einer Protokollbeschreibungssprache definiert ist, die von jeder konkreten Hardware- oder Softwareimplementierung der ersten Datenverarbeitungsvorrichtung unabhängig ist, und

ein Konfigurierungsmittel (209) zum Konfigurieren der ersten Datenverarbeitungsvorrichtung, so daß sie das beliebige Datenkommunikationsprotokoll verwendet, das durch die allgemeine Protokollnachricht definiert wird, wobei das Empfangsmittel in der Lage ist, eine zusätzliche Nachricht in dem beliebigen Datenkommunikationsprotokoll von der zweiten Datenverarbeitungsvorrichtung zu empfangen.