DE69531410T2

DE69531410T2 - Mehrrechnerumgebungen

Info

Publication number: DE69531410T2
Application number: DE69531410T
Authority: DE
Inventors: John Richard Ipswich BARKER; Michael Andrew Kesgrave LUCKING; Christopher James Ipswich CHAPMAN
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1994-12-09
Filing date: 1995-12-08
Publication date: 2004-05-06
Anticipated expiration: 2015-12-09
Also published as: EP0796533B1; KR980700762A; NO972619L; AU689005B2; NZ296583A; FI972404A0; MX9703743A; JPH10510403A; US5931916A; DE69531410D1; CN1169224A; WO1996018256A2; CN1086531C; CA2205068C; NO972619D0; AU4122296A; EP0796533A2; FI972404A; CA2205068A1; WO1996018256A3

Description

Die vorliegende Erfindung betrifft eine Multiprozessor-Umgebung und insbesondere Anordnungen zur Übertragung von Daten zwischen Verarbeitungen, die in solchen Umgebungen ablaufen. In komplexen Systemen, beispielsweise einem Telefonnetzwerk, ist "Intelligenz" an vielen verschiedenen Punkten vorhanden. Eine Reihe von Steuerprozessoren stellen die Hauptfunktionen des Netzwerks zur Verfügung, jedoch ist eine wesentliche Verarbeitungsfähigkeit auch an von den Fernsprechvermittlungsstellen entfernten Standorten vorhanden.
Insbesondere sind intelligente Peripherien, das heißt, Peripherien, die zur Entscheidungsfällung in der Datenverarbeitung befähigt sind, an Orten vorhanden, die näher am Kunden liegen.
Für Einrichtungen, die von einer intelligenten Peripherie zur Verfügung gestellt werden sollen, muß nicht die Erstellung einer physischen Verbindung über ein bestimmtes Netzwerk notwendig sein. So können einige solcher intelligenten Peripherien ein Knoten in mehreren verschiedenen arbeitenden Netzwerken sein. Wenn ein Netzwerk ferner eine Reihe von Hauptrechnern umfaßt, kann es für eine Verarbeitung auf einem davon erforderlich sein, daß dieser direkt mit einer Verarbeitung auf einem anderen Hauptrechner in Interaktion tritt.
Dementsprechend müssen IPC-Kommunikationen zwischen auf verschiedenen Hauptrechnern laufenden Prozessen bzw. Verarbeitungen zuverlässig sein.
Dauerverbindungen zwischen Verarbeitungen sind zwar zuverlässig, sie bedeuten aber aufwendige Investitionen und sind unflexibel. Auf Haupt rechner wird daher üblicherweise über öffentliche Gemeinschaftsnetzwerke, wie z. B. das Internet, zugegriffen.
Das Internet bietet eine einfache Datagramm-Einrrichtung, um den Datentransfer zwischen Hauptprozessen zu ermöglichen. Bei den Übertragungen wird ein einfaches Benutzer-Datagramm-Protokoll (UDP) verwendet, das vom Internet zur Verfügung gestellt wird. Ein derartiges Protokoll ist beispielsweise von Postel, J. in ARPANET Working Group Request for Comments, Nr. 768, beschrieben. Zwar ermöglicht das UDP-Datagramm einen Datentransfer zwischen Prozessen bzw. Verarbeitungen, es ist jedoch kein so zuverlässiges Verfahren zur Übertragung von Daten über Festverbindungen oder öffentlichen Fernsprechwählnetz-Verbindungen (PSTN-Verbindungen).
Frühere Datagramm-Transfer-Einrichtungen, wie z.B. das als TCP bekannte System, führen oft zu einer Verfälschung der im Datagramm enthaltenen Daten, da die Nachrichtengrenzen nicht eingehalten werden und eine beträchtliche Zeit vergehen kann, bis ein Lieferausfall festgestellt wird, wenn eine solche Feststellung überhaupt möglich ist.
Ein früheres System ist in EP 0512174 beschrieben, bei dem jedes Computersystem eine Reihe von Modems hat, die an Kommunikations-Ports angeschlossen sind, um eine raschere Übertragung von Datennachrichten zu unterstützen. So kann in den Systemen nach dem Stand der Technik eine Nachricht in mehrere Segment-Dateien aufgeteilt werden, von denen jede über ein entsprechendes Modem zu einer entsprechenden Bestimmungsadresse gesandt wird. Jedes Modem am empfangenden Computersystem enthält daher jeweils seine eigene Bestimmungsadresse, wodurch ein einzelner Zielcomputer verschiedene Bestimmungsadressen aufweist. Das in EP 0512174 offenbarte System kann immer noch von einem Ausfall betroffen sein, wenn nämlich ein oder mehrere Segmente einer Nachricht verloren gehen.
Die vorliegende Erfindung strebt daher an, ein Verfahren zur zuverlässigen Übertragung von Daten über Netzwerke vom Typ des Internet anzugeben.
Erfindungsgemäß ist ein Verfahren zur Übertragung von Datenpaketen zwischen Verarbeitungen angegeben, die in einer Multiprozessor-Umgebung des Typs ablaufen, der mehrere Hauptrechner umfaßt, wobei auf jeden Hauptrechner an mehreren Netzknotenadressen zugegriffen werden kann, das die folgenden Schritte umfaßt:

– Erstellen einer Hauptrechner-Bestimmungs-Kennung und eines Hauptrechner-Bestimmungs-Ports für jede zu adressierende Verarbeitung,
– Erstellen einer Adressenliste für jede Hauptrechner-Bestimmungs-Kennung, die für jede Übertragung eines Datenpakets mehrere entsprechende Netzknotenadressen enthält,
– Zyklisches Auswählen einer Netzknotenadresse aus der jeweiligen Adressenliste für den Hauptrechner-Bestimmungs-Port, die in der für die Übertragung zwischen den Knoten verwendeten Liste die nächste Adresse ist, bis zur letzten Adresse, und
– Hinzufügen einer Kopfzeile zum Datenpaket, die die ausgewählte Netzknotenadresse und den Bestimmungs-Port vorgibt, gekennzeichnet durch
– Überwachung der Rückdaten zur Paketbestätigung und zur erneuten Übertragung eines beliebigen, nicht bestätigten Datenpakets zur nächsten Netzknotenadresse in der Adressenliste.

Jede Nachrichtenkopfzeile, die zwischen Verarbeitungen versandt wird, kann eine Nachrichten-Sequenznummer enthalten, die vom Sende- Prozessor in der Weise inkrementiert wird, daß der Empfangs-Prozessor Nachrichten in der richtigen Reihenfolge umordnen und das Fehlen einer oder mehrerer Nachrichten in einer Nachrichtensequenz erkennen kann.
Bei längeren Datenpaketen kann die Kopfzeile auch eine Stückzahl in Bezug auf das spezielle Datenpaket, das übermittelt wird, enthalten. Wenn mehr als eine Verarbeitung auf einem ersten Hauptrechner mit einer oder mit mehreren Verarbeitungen auf einem zweiten Hauptrechner in Interaktion sind, repräsentiert die Sequenznummer Nachrichten, die zwischen den Knoten übertragen werden und kann auch nicht die gleiche Sequenz wie die Stückzahl haben, die eine Serie von Port-Nachrichten repräsentiert, die zwischen Verarbeitungen übertragen werden, um eine Rückversicherung in Bezug auf eine vollständige Nachricht vor Durchführung der Verarbeitung für den empfangenden Benutzer zu ermöglichen.
Ein dezentralisiertes Mehrprozessor-Netzwerk, das das Verfahren der Erfindung anwendet, ist im folgenden lediglich beispielhaft unter Bezug auf die beigefügten Zeichnungen beschrieben, in denen zeigen:
1 eine schematische Darstellung eines Teils eines Telekommunikationssystems,
2 eine schematische Darstellung eines Blockdiagramms des dezentralizierten Multiprozessor-Netzwerks,
3 eine schematische Darstellung einer Prozeß-Interaktion mit den Kommunikationsprozessen des Netzwerks von 2,
4 eine schematische Darstellung der im Protokoll verwendeten Daten- und Kopfzeilen-Informationen,
5 ein Zustandsübergangs-Diagramm, das das Sendeende der Prozessoraktivität zeigt,
6 ein Zustandsübergangs-Diagramm, das das Empfangsende der Prozessoraktivität zeigt,
7 bis 9 Ablaufdiagramme, die den Betrieb eines der Module von 3 im Sendeknoten der Anordnung von 1 zeigt,
10 bis 13 Ablaufdiagramme, die einen Teil des Betriebs der Module von 3 im Empfangsknoten zeigen.
In 1 ist eine typische Kommunikationsanordnung einer Fernsprechvermittlungsstelle gezeigt, die eine Reihe von Steuerprozessoren 1 (nur einer ist gezeigt) und Ressourcen 2 umfaßt, die Funktionen, wie Schalterwahl, Telemetrie und andere, auf Netzwerken beruhende Dienste zur Verfügung stellen.
Wenn daher ein Steuerprozessor 1 anhand des Laufs von Anwendungs-Software 3 erkennt, daß eine bestimmte Ressource 2 verwendet werden soll, um eine angeforderte Funktion zu erfüllen, ist es erforderlich, daß der Steuerprozessor 1 Informationen in Form einer Nachricht zur Ressource 2 überträgt.
Um eine derartige Operation zum Abschluß zu bringen, enthält der Steuerprozessor Kommunikations-Software, wie sie schematisch unter 4 dargestellt ist, sowie eine Reihe von Telekommunikations-Ausgangsports 5.
Die Telekommunikations-Ausgangsports 5 werden mit Hilfe von einem oder mehreren Netzwerken mit der benötigten Ressource verbunden. Diese Netzwerke sind schematisch als Nachrichten-Schnittstelle 6 in 1 dargestellt. Weitere Einzelheiten des Betriebs der Nachrichtenübermittlung gehen aus der nachfolgenden Beschreibung hervor.
In der Ressource 2 sind entsprechende Kommunikationsports 7 vorgesehen, um Nachrichten über verschiedene Netzwerke zu empfangen.
Es wird zusätzlich auf 2 Bezug genommen, in der eine Reihe von Knoten 10-1n gezeigt ist, von denen jeder mit Hilfe von entsprechenden Kommunikationsports 10a, 10b, 10c, etc. mit einer Reihe von Netzwerken 20-2m verbunden ist, wobei diese Ports für die Kommunikationsports 5 und 7 von 1 repräsentativ sind. Es ist anzumerken, daß die Verbindungsmuster der Knoten 10-1n variieren und nicht alle Knoten mit allen Netzwerken verbunden sind. So ist z. B. Knoten 10 durch seine entsprechenden Ports mit den repräsentativen Netzwerken 20, 21 und 2m verbunden, wohingegen der Knoten 11 nicht mit dem Netzwerk 21 sondern mit Netzwerk 22 verbunden ist.
Wie bereits oben angegeben, ist die Kommunikations-Verbindung für die Netzwerke 20-2m der Art, wie sie mitunter im Internet vorhanden sind, das mit einem einfachen Datagramm-Transfer-Protokoll ausgestattet ist, das als UDP (User Datagramm Protocol) bekannt ist. Die Benutzer-Datagramm-Protokolle haben eine Prozedur für die Anwendung von Programmen, um Nachrichten an andere Programme zu senden. Die zu übertragende Nachricht wird als Anzahl von Daten-Bytes zusammengetragen, der das Kommunikationsprotokoll eine Quellen-Kennung, eine Bestimmungskennung und Längen-Bytes und Kontrollsummen-Bytes hinzufügt. Das UDP-Software-Modul verwendet eine Quellenadresse und eine Bestimmungsadresse zur Bildung der Internet-Kopfzeile und bewirkt die Übertragung einer Datennachricht zwischen zwei Prozessoren. Eine typische UDP-Nachricht ist schematisch in 4 dargestellt, auf die später Bezug genommen wird.
In 1 und 3 ist die Software zur Steuerung der Ressourcen 2 und die Anwendungssoftware 3 im Steuerprozessor 1 von 1 durch die Benutzerverarbeitungen 31-3p dargestellt. Wenn eine Benutzerverarbeitung 31-3p eine Übertragung von Informationen zu einer anderen Benutzerverarbeitung 31-3p auf dem gleichen oder einem anderen Prozessor benötigt, stellt sie ein Datagramm zusammen, das eine Bestimmungs-Kopfzeile und die zu übertragenden Daten enthält.
Gemäß 4a wird in bekannten Systemen das Datagramm 40 an eine UDP-Verarbeitung 41 im Prozessor zusammen mit dem Bestimmungsknoten (Internet-Adresse) und Port-Adresse in einer Kopfzeile 42 gesandt. Die UDP-Verarbeitung 41 verwendet die Internet-Adresse aus der Kopfzeile 42 und setzt in ihrer eigenen Kopfzeile 43 weitere Informationen hinzu. Diese weiteren Informationen sind: die Port-Adresse 44 der Quellen-Verarbeitung 31-31p, ein Längen-Byte 45, das vom Datagramm 40 bestimmt wird, und ein Kontrollsummen-Byte 46, das an dem Bestimmungsknoten verwendet werden kann, um zu überprüfen, ob bei der Übertragung ein Fehler aufgetreten ist.
Die UDP-Verarbeitung 41 sendet das komplette UDP-Datagramm 47 an das Internet-Protokoll-Modul 48, das das Datenpaket mit Hilfe eines geeigneten Treibers 49 zur Bestimmungsverarbeitung zu einem Netzwerk (z. B. 20) überträgt. Am Ziel gehen die vom Netzwerk 20 empfangenen Daten durch den entsprechenden Treiber 49 und das Internet-Modul 48 zum UDP-Modul 41 und somit zur Bestimmungsverarbeitung 31-3p.
Im System der Erfindung wird eine weitere Verarbeitung zwischen den Benutzerverarbeitungen 31-3p und der UDP-Verarbeitung 41 eingeführt. Dieses Verfahren, der RDP-Treiber 50, erhält das Datagramm von den Benutzerverarbeitungen 31-3p mit Hilfe der Betriebssystem-Schnittstellen 51-51p. Diese Schnittstellen können für einen Datentransfer in Systemen verwendet werden, die nur die UDP-Verarbeitung 41 nutzen und sie sind effektive Datenspeicherbereiche, die für die Übertragung von Daten durch die Verarbeitungen in Speicherbereichen verwendet werden, die für diese Zwecke bestimmt sind. Es wird hier zusätzlich zu 4b Bezug genommen, in der die Kopfzeile 42 einen RDP-Knoten 61 und eine RDP-Port-Adresse 62 übermittelt.
In einigen Systemen sammeln die Benutzerverarbeitungen 31-3p Datagramme, die in Speicherbereiche zu übertragen sind, die durch die Benutzerverarbeitung zugewiesen werden. Danach wird mit Hilfe der Betriebssystem-Schnittstelle 51-51p die Adresse des gespeicherten Datagramms zum RDP-Modul 50 übertragen, das dann das Datagramm wieder aus dem speziellen Speicherbereich zur weiteren Verarbeitung aufruft. In anderen Fällen kann das zusammengesetzte Datagramm direkt über die Betriebssystem-Schnittstelle 51-51p übertragen werden.
Im Empfangsknoten stellt das RDP-Modul 50 das Datagramm nach seinem Empfang für eine Empfangs-Verarbeitung 31-3p in einen Speicherplatz, der einer Port-Schlange zugeordnet ist.
Der Bestimmungsknoten 61 wird im RDP-Treiber 50 mit Hilfe einer Nachschlagetabelle betrachtet, um festzustellen, auf welchen Netzwerken mit denen der Quellenknoten verbunden ist, der Bestimmungsknoten auftaucht. Wenn daher gemäß den 2, 3 und 4 eine Verarbeitung, die im Knoten 10 abläuft, die Übertragung eines Datagramms 40 zu einer Verarbeitung 32 erforderlich macht, die im Knoten 12 abläuft, dann werden beide Knoten über die Netzwerke 20 und 21 vom Ethernet-Typ verbunden. Somit wählt der RDP-Treiber 50 eines dieser Netzwerke aus und die Bestimmungsknotenadresse (16) in einem Byte (DN) von 16 Bit übertragen. Der Bestimmungsport ist als ein 16-Bit-Byte (DP) zusammengestellt, und der Quellenknoten (SN) und der Quellen-Port (SP) sind in ähnlicher Weise gekennzeichnet.
Um Mißverständnissen vorzubeugen, wird angemerkt, daß die Benutzerverarbeitungen 31-3p nur eine einzige Knotenadresse in Bezug auf die Bestimmungsverarbeitung verwenden, und die Knotenadresse 61 dient ebenfalls einer Verwendung durch UDP, und dieser Übergang, der vom RDP-Modul 50 auf eine von mehreren Internet-Adressen umgesetzt wird, ist für den Benutzer transparent.
Es wird ebenfalls angemerkt, daß die Adressenliste für eine virtuelle (RDP) Adresse durch eine Benutzeraktion modifiziert werden kann, um zusätzliche oder alternative Adressen auch während der Übertragung von Datenpaketen zu diesem Logikknoten anzugeben. Ebenso ist die Entfernung von Adressen aus der Adressenliste möglich, und eine Übertragung nachfolgender Datagramme zum Bestimmungsknoten verwendet die revidierte Adressenliste. Damit ist es dem Benutzer möglich, Netzwerke im Betrieb zu ändern ohne Verlust von beliebigen Datagrammen im Transit zwischen den Ports auf den Knoten.
Es ist anzumerken, daß jede Übertragung zwischen Knoten die nächste verfügbare Adresse von der Adressenliste verwendet, es sei denn, daß die Adresse mit dem Vermerk "betriebsunfähig" versehen wurde. Wenn da her mit einer virtuellen (RDP) Adresse mehr als eine Internet-Adresse verbunden ist, dann werden die Internet-Adressen zyklisch verwendet.
Die anderen Bytes in der RDP-Kopfzeile 63 umfassen ein acht-Bit-Fehlerfeld (E), ein Flag-Feld (FL), Stücknummern und Sequenznummern (FRAG bzw. SEQ und ein Datenlängenfeld. Die letzteren drei Felder haben jeweils 32 Bit. Das Flag-Byte (FL) gibt folgendes an:
Wenn die Übertragung eines Datagramms zwischen einer Benutzerverarbeitung und einer anderen Benutzerverarbeitung betrachtet wird, läßt sich die vorliegende Erfindung noch besser verstehen. Die zu übertragenden Daten, d. h., die von der Benutzerverarbeitung (z. B. 31) gelieferten Daten, werden in das RDP-Datagramm gepackt, das wiederum in ein UDP-Datagramm gepackt wird, d. h. das komplette RDP-Datagramm einschließlich seiner Kopfzeile wird als ein Datagramm der in 4a gezeigten Form behandelt, der eine geeignete UDP-Kopfzeile 43 hinzugefügt wurde.
Die Bestimmungsknotenkennung DN wird in eine geeignete Internet-Bestimmungsadresse übersetzt und das Datagramm wird zu seinem Bestimmungsknoten übertragen. Die übertragende RDP-Verarbeitung startet eine Zeitüberwachung. Wenn, unabhängig vom Port innerhalb des Knotens von dem das Datagramm stammt, dieses die erste Nachricht zwischen den zwei Knoten ist, wird das Flag "S" "Festlegen der Sequenz" im Byte FL gesetzt und das Sequenz-Byte (SEQ enthält eine Nummer. Für den Augenblick sollen die Bytes ignoriert werden, die sich auf die Stückelung eines Datagramms beziehen. Das UDP-Modul 41, das wie oben beschrieben arbeitet, schickt das Datagramm und die RDP-Kopfzeile zum Bestimmungsknoten. Am Bestimmungsknoten wird die UDP-Kopfzeile entfernt und das Datagramm wird zum RDP-Treiber 50 des Bestimmungsknotens 12 weitergeleitet. Die im RDP-Treiber 50 des Ursprungsknotens 10 gestartete Zeitüberwachung erwartet den Empfang eines Datagramms vom Bestimmungsknoten 12.
Bei Empfang einer ersten Nachricht setzt der RDP-Treiber 50 des Bestimmungsknotens 12 seine Sequenznummer für den Empfang von Datagrammen vom jeweiligen Quellenknoten, gekennzeichnet durch das SN-Byte auf den im Sequenz-Byte angegebenen Wert. Der empfangende RDP-Treiber sendet ein Datagramm mit Sequenznummer zurück, wobei das Bestätigungs-Bit (A) im Flag-Feld gesetzt ist.
Das erste, zwischen dem Sendeknoten 10 und dem Bestimmungsknoten 12 übertragene Datagramm enthält gegenwärtig irgendwelche Daten von einer Benutzerverarbeitung, obwohl das möglich wäre. Das Datenlängen-Byte wird auf Null gesetzt und es folgen keine Daten. Bei einer Weiterentwicklung dieses Systems wird das erste übertragene Datagramm verwendet, ein Gleitfenster einzurichten, das die Zahl der Datagramme bestimmt, die zwischen einem Sendeknoten und einem Bestimmungsknoten übertragen werden können, bevor eine Bestätigung gesendet wird.
In diesem Fall enthält der Knoten, wenn die erste Übertragung vom Sendeknoten 10 erfolgt, einen Wert und das Sendeende ist darauf eingerichtet, zu bis diesem Wert als zu einem Maximum zu arbeiten. Beim Empfang akzeptiert der Bestimmungsknoten 12 entweder den vom Sendeende vorgeschlagenen Wert, wenn dieser innerhalb der Kapazität des Empfangsknotens liegt; wenn jedoch der Empfangsknoten 12 eine maximale Kapazität (Fenster) hat, die unter dem vom Sendeknoten 10 vorgeschlagenen Wert liegt, dann gibt der Bestimmungsknoten 12 unter Zurücksendung eines ACK (Bestätigungssignals) an den Sendeknoten seinen eigenen maximalen Wert an. Der revidierte Wert wird dann vom Sendeknoten 10 übernommen.
Wenn eine Bestätigung der ersten Übertragung von der RDP-Verarbeitung 50 des ersten Knotens 10 nicht vor dem Zeitablauf empfangen wurde, versucht der RDP-Treiber 50, dasselbe Datagramm mit Hilfe eines alternativen Netzwerks, z. B. 21, zu senden und markiert den ersten RDP-Übergang, d. h. welcher spezielle Knoten 12 am Netzwerk 20 ausgefallen ist. Wenn eine vorgegebene Anzahl von Übertragungsversuchen zu einer speziellen Adresse, die durch den RDP-Übergang bestimmt ist, fehlschlägt, dann kann das RDP-Modul 41 das als Verbindungsausfall kennzeichnen und markiert die Verbindung als "betriebsunfähig", bis ein Test-Datagramm Erfolg hat, die spezielle Verbindung als wieder eingerichtet zu kennzeichnen.
Es ist anzumerken, daß mehr als eine Verarbeitung Daten zwischen den Knoten 10 und 12 gleichzeitig übertragen kann und solche Daten sequentiell übertragen werden, wenn eine erste erfolgreiche Datenübertragung stattgefunden hat, und der ursprüngliche Sendeknoten 10 ein gültiges Rück-Datagramm einschließlich der korrekten Sequenznummer und dem Setzen des Flag "A" empfangen hat. Die nachfolgenden Datagramme werden vom Quellenknoten 10 gesendet, ohne daß das Flag "S" gesetzt wird.
Die RDP-Verarbeitung 50 kann eine Reihe von Versuchen zur Versendung eines Datagramms zwischen dem Quellenknoten 10 und dem Bestimmungsknoten 12 unternehmen, und sie wird die Versuche zur Übertragung des Datagramms mit Hilfe von verschiedenen Netzwerkadressen solange fortsetzen, bis eine vorgegebene Anzahl von Versuchen unternommen worden ist. Wenn die vorgegebene Anzahl von Versuchen unternommen worden ist, wird an die ursprüngliche Verarbeitung am Quellenknoten eine Fehlermeldung zurückgesandt, die besagt, daß der Empfangsknoten ausgefallen ist. Weitere Versuche zur Einrichtung einer Übertragungsstrecke zwischen den zwei Knoten werden durchgeführt, wobei eine neue Sequenznummer verwendet wird, wie oben für die Initialisierung der Übertragung von Datagrammen zwischen zwei Knoten beschrieben ist.
Indem Bestätigungen, Rücksendung, Sequenznummern und Mehrfach-Ethernet-Verbindungen verwendet werden, wird eine Zuverlässigkeit der Datenübertragung zwischen Datenverarbeitungen auf getrennten Knoten erzielt. Der Link zwischen einer Sendeverarbeitung (31-3p), die als ein Port in einem Knoten arbeitet, und einer Empfangsverarbeitung 31-3p, die als ein Port in einem anderen Knoten arbeitet, ist verbindungslos. Infolgedessen kann eine Sendeverarbeitung eine Reihe von Datagrammen an verschiedene Empfangsverarbeitungen gleichzeitig senden. Gleichermaßen kann eine Empfangsverarbeitung Datagramme von einer Reihe von Sendeverarbeitungen erhalten.
Nachdem ein Datenübertragungspfad mit einer bestätigten Sequenznummer eingerichtet wurde, werden vom Quellenknoten zum Bestimmungsknoten Datagramme mit ansteigenden Sequenznummern gesendet. Der RDP-Treiber 50 hält eine Kopie aller übermittelten Nachrichten solange, bis eine Bestätigung der übermittelten Nachricht erhalten wurde. Eine nachfolgende Nachricht wird nur von einem ersten Knoten zu einem zweiten Knoten gesendet, wenn eine Bestätigung erhalten worden ist. In einem bevorzugten Betriebsverfahren, auf das oben Bezug genommen worden ist, in dem ein Fenster von "N" Nachrichten akzeptabel ist, bevor eine Bestätigung erhalten wird, können jedoch Nachrichten solange in Folge übertragen werden, bis die maximale Anzahl der austehenden ACK, die für die Datagramme erwartet wird, gesendet worden ist. Somit werden Sequenznummern durch den RDP-Treiber 50 des Sendeknotens für jedes übertragene Datagramm inkrementiert und werden zurückgesetzt, wenn keine Bestätigung erhalten wird. Der empfangende RDP-Treiber 50 prüft die Nachrichten-Sequenznummer nach Ankunft jedes Datagramms. Der RDP-Treiber 50 im Empfangsknoten 12 hat eine begrenzte Zahl von Sequenznummern, die er als gültig akzeptieren kann. Wenn der Treiber eine Sequenznummer erhält, die nicht richtig ist, die außerhalb des erlaubten Maximums liegt, oder wenn ein anderer Fehler aufgetreten ist, wenn z. B. der Hauptrechner-Bestimmungs-Port, der in der Kopfzeile des Datagramms angegeben ist, dem empfangenden RDP-Treiber unbekannt ist, sendet er ein Datagramm mit dem Flag "N" zurück und veranlaßt somit das Ursprungs-RDP-Modul in Abhängigkeit vom Grund für den Ausfall, entweder das ursprüngliche Datagramm erneut zu übertragen oder das Datagramm an die Ursprungs-Verarbeitung zurückzusenden.
Es ist hier anzumerken, daß durch ein rasches Identifizieren eines beliebigen Ausfalls und sofortiges Zurücksenden eines Negativsignals (NACK) durch den Sendeknoten jeder beliebige Ausfall rasch bemerkt werden kann.
Die RDP-Verarbeitung 50 des Empfangsknotens 12 erwartet den Empfang eines nächstfolgenden Datagramms. Unter der Voraussetzung, daß die Sequenznummer des empfangenen Datagramms sich innerhalb der Grenze des Gleitfensters derart befindet, daß das empfangene Datagramm nicht mehr als "N" größer als das letzte empfangene und bestätigte Datagramm ist, dann behält das Modul das letzte empfangene Datagramm bis zum Empfang früherer numerierter Datagramme. Wenn im Empfangsmodul eine Zeitüberwachung abläuft oder die Sequenznummer eines später erhaltenen Datagramms höher als die Sequenznummer eines früher erhaltenen Datagramms ist, sendet das Empfangsmodul eine Bestätigung in Bezug auf das letzte konsekutiv empfangene Datagramm mit Sequenznummer. Diese Bestätigung bestätigt dem Sendemodul ebenfalls alle früheren Datagramme mit Sequenznummern. Bei Empfang der Bestätigung kann die RDP-Verarbeitung 50 des Sendeknotens 10 ihr Sendefenster zurücksetzen, in welchem durch das letzte bestätigte, vom Empfangsknoten 12 empfangene Datagramm eine Anzeige in diesem Maße erfolgt. Wenn der Unterschied zwischen dem gegenwärtig gesendeten Datagramm mit Sequenznummer und dem letzten bestätigten Datagramm mit Sequenznummer "N" erreicht, läuft eine Zeitüberwachung ab. Weitere Datagramme werden gesendet, bis eine Bestätigung erhalten wird, ist das aber nicht der Fall, bis eine erneute Übertragung des früheren Datagramms stattfindet.
Wie oben angemerkt, kann die Anzahl der Datagramme, die ohne Empfang einer Bestätigung versandt werden, zwischen dem Ursprungsknoten 10 und dem Empfangsknoten 12 ausgehandelt werden. Darüber hinaus kann eine weitere Sicherungsmaßnahme Datagramme einschließen, die vom empfangenden RDP-Treiber mit dem Flag "N" gesendet und vom Ursprungs-RDP-Treiber 50 bestätigt werden, bevor irgendwelche Bestätigungen für ein Datagramm, das dem angefochtenen Datagramm folgt, gesendet werden. Wenn einmal angenommen, daß das System mit einem Sequenznummernfenster von 10 arbeitet, und das Datagramm 3, nachdem die vorherigen Datagramm-Sequenzummern 1, 2, 4, 5, etc. erhalten wurden, noch nicht erhalten wurde, sendet daher das RDP-Treiber-Modul 50 im Empfangsknoten 12 eine Bestätigung für Datagramm 2. Das sendende RDP-Modul 50 sendet dann nach dem Ende der Störung das Datagramm 3 erneut.
Bei Empfang des Datagramms 3 kann das RDP-Modul 60 des Empfangsknotens 12 nun eine Bestätigung früher erhaltener Datagramme mit höheren Sequenznummern übertragen, so daß eine Bestätigung beispielsweise von Datagramm 8 die Antwort auf die erneute Übertragung von Datagramm 3 sein kann.
Wenn die Bestimmungs-Benutzer-Verarbeitung am Empfangsknoten 12 die Datagramme nicht so schnell annehmen kann, wie sie erhalten wer den, ordnet das RDP-Modul 50 jedes empfangene Datagramm in eine Schlange ein. Wenn der Hauptprozessor in Bezug auf die Größe der Schlange beschränkt ist und die Zahl der empfangenen und in eine Schlange eingeordneten Datagramme zu hoch wird, hält das Bestimmungs-RDP-Modul 50 Bestätigungen zum Sendeknoten 10 eine kurze Zeit lang zurück, während es erneut versucht, das Datagramm in die Schlange einzuordnen. Es können eine Reihe von Versuchen unternommen werden, das Datagramm in die Schlange zu bringen, wenn jedoch die Höchstzahl der Wiederholungsversuche erreicht ist, wird eine Negativbestätigung mit dem Datagramm zum Ursprungsknoten 10 zurückgesandt, wodurch dieser Knoten das ausgefallene Datagramm erneut zur Benutzerverarbeitung zu senden versucht.
Normalerweise schickt das RDP-Modul keine Lieferbestätigung eines Datagramms an die Benutzerverarbeitung, da die Benutzerverarbeitung wegen dessen Zuverlässigkeit nicht erwartet, eine solche Bestätigung zu erhalten. Eine Benutzerverarbeitung kann aber eine Betätigung speziell anfordern, woraufhin bei Empfang einer Bestätigung vom Empfangsknoten das RDP-Modul eine Lieferbestätigung über die Betriebssystem-Schnittstelle 51–50 sendet.
Wenn der RDP-Ursprungstreiber 50 eine Bestätigung mit einer Sequenznummer erhält, die nicht einem beliebigen der Datagramme, d entspricht, die ausgesandt wurden, für die aber eine Bestätigung noch nicht erhalten wurde, ignoriert er die Bestätigung. Wenn die Zeitüberwachung abläuft, wird eine beliebige ausgefallene Übertragung von der Quelle zur Bestimmungsadresse korrigiert.
In der Empfangsnotiz kann das RDP-Modul Datagramme akzeptieren, die mit einer Sequenznummer erhalten wurden, die sich im Bereich von (n – s) bis ((n + s) – 1) befindet, wobei n die niedrigste erhaltene, aber noch nicht bestätigte Sequenznummer und s die Nummer der Datagramme ist, die das Sende-Modul aussenden kann, ohne eine Bestätigung zu erhalten. In diesem Fall wird die zurückgesandte Bestätigung diejenige mit der Sequenznummer des Datagramms sein, das in der Reihenfolge als letztes erhalten wurde. Diese Situation kann auftreten, wenn der empfangende RDP-Treiber eine Bestätigung für ein früher empfangenes Datagramm aussendet und seine Sequenznummer fortschaltet, aber die zurückgesandte Bestätigung nicht vom Quellenknoten erhalten wurde. Wenn die Zeitüberwachung im ersten RDP-Treiber abläuft, versucht der erste RDP-Treiber 50 am Quellenknoten 10 eine erneute Übertragung.
Es ist anzumerken, daß bei jeder Gelegenheit, bei der ein neuer Übertragungsweg zwischen zwei Knoten eingerichtet werden muß, das eingestellte Sequence-Flag und die Sequenznummer vom Quellenknoten zum Bestimmungsknoten übertragen werden. Wenn ein Datenaustausch in beiden Richtungen stattfindet, finden separate Übertragungen statt, das heißt, in einem Fall stellt anfangs der Quellenknoten, beispielsweise 10, die Sequenz durch die Aussendung einer ersten Nachricht zum Bestimmungsknoten 12 ein, und eine separate Sequenz von Nachrichten wird vom Knoten 12, als dem Quellenknoten, zum Knoten 10, als dem Bestimmungsknoten, begonnen. Übertragungen in der ersten Richtung, d. h. vom Knoten 10 zum Knoten 12, können ein anderes Netzwerk für die Übertragungen zwischen dem Knoten 12 und dem Knoten 10 verwenden.
Im folgenden sollen nun das Stück-Byte FRAG und das erste und letzte Stück-Flag F und L betrachtet werden. Wenn ein Datagramm 40, das von einer Benutzerverarbeitung 31-3p erhalten wurde, eine signifikante Länge aufweist, kann es erforderlich sein, daß dieses Datagramm in ei ner Reihe von Stücken gesendet wird. Ist das der Fall, gibt die erste Übertragung zwischen den zwei Knoten an, daß das Stück das erste Stück F ist, und eine Stück-Nummer hat, die gleich 1 oder nicht gleich 1 sein kann. Bei jeder Übertragung eines folgenden Abschnittes des Datagramms 40 nimmt die Stücknummer FRAG um Eins zu, bis das letzte Stück des speziellen Datagramms 40 übertragen wurde, wobei das Flag L gesetzt wird.
Das komplette Datagramm 40 kann am Bestimmungsknoten wieder zusammengesetzt werden, auch wenn die Stücke des Datagramms nicht in der richtigen Reihenfolge erhalten wurden, da die Übertragungsdaten eine Anzeige enthalten, welches Stück das erste und welches das letzte ist, und da in FRAG ein sequentielles Nummern-Schema verwendet wird. Es ist anzumerken, daß wenn eine Stückelung von Datagrammen für Benutzerverarbeitungen nicht erforderlich ist, was die Norm sein kann, die der Stück-Verarbeitung zugeordneten Bytes und Bits für andere Zwecke verwendet werden können, oder sie müssen auch gar nicht vorhanden sein. Wenn eine Stückelung verwendet wird, dann können nicht-gestückelte Datenpakete , die zwischen Knoten übertragen werden, sowohl ein erstes als auch ein letztes Stück-Bit (F und L) im FLAG-Byte (FL) gesetzt haben. Andere Reserve-Bytes können in der Kopfzeile vorgesehen sein, um eine nachfolgende Erweiterung der Funktionen des Systems zu ermöglichen. Das kann während der ursprünglichen Einstellung der Übertragungen zwischen zwei Knoten angegeben werden.
Es ist anzumerken, daß wenn eine Anzahl von Verarbeitungen, die als verschiedene Ports eines bestimmten Knotens laufen, mit einer oder mehreren Verarbeitungen kommunizieren, die als Ports des gleichen Bestimmungsknotens laufen, dann muß es sich bei dem Austausch von Nachrichten zwischen den zwei Knoten nicht kontinuierlich um die Stücke eines Datagramms handeln.
Wenn zu einer beliebigen Zeit mehrere Datagramme vom RDP-Modul 50 behandelt werden, was zu einer Schlange von Datagrammen führt, die auf eine Übertragung durch einen Sendeknoten zu einem Empfangsknoten warten, dann wird ein beliebiges Datagramm, welches die Benutzerverarbeitung 31-3p als Datagramm mit hoher Priorität gekennzeichnet hat, indem sie das Bit "p" in das Byte FL gesetzt hat, vom Modul 50 vor der Behandlung einer beliebigen anderen Datagramm-Übertragung behandelt. Bei mehreren Datagrammen mit hoher Priorität werden die Datagramme mit hoher Priorität in der Reihenfolge des Empfangs vom RDP-Modul 50 in einer Schlange angeordnet.
In dem oben beschriebenen Falle, kann die RDP-Verarbeitung, wenn eine spezielle Bestimmungsadresse für einen speziellen RDP-Bestimmungsknoten als nicht funktionsfähig bezeichnet wurde, Testnachrichten solange auf der ausgefallenen Übertragungsstrecke senden, bis sie für diese Nachricht eine Bestätigung erhält. Solche Nachrichten werden durch Setzen des Flag "T" im Flag-Feld gekennzeichnet. Wenn einmal eine oder mehrere erfolgreiche Testnachrichten übertragen wurden, wird die Marke, die die Nichtverfügbarkeit der Adresse anzeigt, ausrangiert. Zum Zweck einer Überprüfung ausgefallener Übertragungsstrecken werden keine lebenden Daten verwendet.
Bei der ersten Markierung, daß eine bestimmte Bestimmungsadresse in der Adressenliste nicht funktioniert, kann das RDP-Modul 50 einem Port an seinem Knoten mitteilen, daß diese bestimmte Adressenverbindung mit diesem Port ausgefallen ist und diese Adresse herausgenommen worden ist. Eine solche Mitteilung kann von einem Prozeß, der an diesem Port in Betrieb ist, verwendet werden, um den Benutzer auf den Ausfall einzelner Internet-Verbindungen zwischen Knoten aufmerksam zu machen; der Benutzer würde ansonsten solch einen Verbindungsausfall nicht bemerken.
Es ist anzumerken, daß die Befähigung der RDP-Treiber 50, Datagramme zu erkennen, die nicht an ihrem Bestimmungsort angekommen sind, und ein Datagramm neu zu erstellen, wenn Stücke nicht in einer bestimmten Reihenfolge (falls zutreffend) erhalten wurden, ist eine signifikante Verbesserung der Zuverlässigkeit, verglichen mit der normalen UDP-Verarbeitung ist. So wird ein beliebiger Ausfall eines der Netzwerke 20-2m von der RDP-Verarbeitung überwunden und die Wiederholungsversuche, die mitunter wegen miteinander gekoppelter Verarbeitungen notwendig sind, die nur UDP verwenden, können unterbleiben.
In 5 befindet sich der Sendezustand, nachdem die Initialisierung der Maschine einmal abgeschlossen ist, durch Zurverfügungstellung der Adressenliste der Bestimmungsknoten und dergleichen in der Ruhestellung, im Zustand "Warte mit dem Senden des festgelegten Sequenzzustands". Bei Empfang eines gültigen Datagramms von einer Benutzerverarbeitung und unter Bezugnahme auf die 7 und 4b, speichert die RDP-Verarbeitung 50 von 3 temporär das Datagramm (Schritt 700) und bereitet ein neues Datagramm zur Übertragung vor, wobei von der Adressenliste in Bezug auf den angegebenen Bestimmungsknoten eine neue Netzwerk-Bestimmungsknoten-adresse (Schritt 705) geholt wird. Das Feld DN des Datagramms wird auf die gegebene Adresse eingestellt. Die Bestimmungsportadresse wird im Schritt 715 zum Bestimmungsportfeld DP übertragen und eine Nachrichten-Sequenznummer, die zur Verwendung in der augenblicklichen Übertragungsrunde vorgeschlagen wurde, wird im Schritt 720 in das Bit "SN" eingesetzt. Schließ lich wird das Flag "S" im Feld FL der RDP-Kopfzeile 63 auf 1 gesetzt, bevor im Schritt 730 ein Zeitgeber gestartet wird, wobei diese Zeit für eine erneute Übertragung ungefähr gleich der maximalen Zeit ist, die eine beliebige Adresse, die für diesen Knoten relevant ist, zur Übertragung eines Datagramms zu einem Empfangsknoten und für den Rückerhalt einer Bestätigung benötigt, multipliziert mit dem Bestätigungsfenster plus 2. Nun wird im Schritt 735 das komplette RDP-Datagramm dem UDP-Modul 41 der 3 zusammen mit der zyklischen Adresse des Bestimmungsknotens von der Adressenliste (erhalten in Schritt 205) für die Übertragung ins Internet weitergegeben. Das RDP-Modul 50 gibt nun den Zustand 80 ein "Warte auf das Einstell-Fenster".
Der Zustand 80 "Warte auf das Einstell-Fenster" ist im einzelnen in 8 gezeigt, auf die nun Bezug genommen wird. Es entsteht ein erster Ausgangsweg, wenn ein Datagramm vom Empfangsknoten unter Verwendung des UDP-Moduls 41 von 3 empfangen wurde. Die RDP-Verarbeitung 50 fordert das leere Feld im Schritt 810 auf, festzustellen, ob das Einstell-Bit "S" gesetzt wurde. Wenn das Bit "S" gesetzt wurde, wird dann im Schritt 815 das Sequenznummern-Bit geprüft, um festzustellen, ob es Null ist oder die ursprüngliche Nachrichten-Nummer aufweist.
Ist die Sequenznummer Null, zeigt das an, daß das Empfangsende befähigt ist, mit Datagrammen zu arbeiten, die nicht sequentiell erhalten wurden, und im Datagramm-Teil 40 wird die maximale Fenstergröße gehalten. Vorausgesetzt, daß der im Datagramm 40 gehaltene Wert N nicht den maximalen Wert N überschreitet, für den der Sendeknoten zu arbeiten ausgelegt ist, wie im Schritt 820 bestimmt wurde, dann wird im Schritt 825 der Fensterwert auf N gesetzt, ansonsten wird im Schritt 830 das Fenster auf den maximalen Wert gesetzt, mit dem das Sendeende arbeiten kann. Nun wird ein Bestätigungs-Datagramm für das eingestell te Fenster zum Empfangsende gesendet, wobei dieses ein Datagramm enthält, bei dem ein Bestätigungs-Bit und ein Einstell-Bit im Flag-Feld eingestellt ist, die Sequenznummer auf Null gesetzt ist und das Datagramm auf die Fenstergröße eingestellt ist, die vom Sendeknoten in den Schritten 825 und 830 gewählt wurde. Nun gibt das RDP-Modul den Zustand 100 "Warte auf Bestätigung der festgelegten Sequenz" ein.
Wenn jedoch bei Schritt 815 festgestellt wurde, daß die Sequenznummer nicht Null ist, wird das Bestätigungs-Bit bei Schritt 805 angefordert. Ist das Bestätigungs-Bit eingestellt, würde das bedeuten, daß das Empfangsende es erforderlich macht, daß nur mit einer einzigen, zu einer beliebigen Zeit übertragen Nachricht gearbeitet wird. Wenn angenommen wird, daß das Bestätigungs-Bit nicht bei Schritt 805 eingestellt wird, wird im Schritt 840 festgestellt, ob die Negativ-Bestätigung eingestellt wurde und, wenn das nicht der Fall ist, wird das Fenster ??? nicht aktiviert. Wenn aber im Schritt 840 das Negativ-Bestätigungs-Bit gesetzt wurde, bedeutet das, daß es einen Fehler beim Kommunikationsversuch gibt und daß beliebige Datagramme, die für eine Übertragung zu diesem speziellen Bestimmungsknoten und -Port gehalten werden, mit einer Fehlerkennung im Schritt 845 vor der Eingabe des Zustands "Warte mit dem Senden des festgelegten Sequenzzustands" zur erneuten Initialisierung der Kommunikation zwischen dem Sende- und dem Empfangsknoten an den Benutzer zurückgesandt werden.
In 9 werden im Zustand "Warte auf Bestätigung" die folgenden Ereignisse erkannt: der Ablauf der vorher eingestellten Zeitüberwachung, ein Datagramm vom UDP-Modul 41, das ein Bestätigungs-Bit enthält, der in das Flag-Feld der Kopfzeile 63 gesetzt wurde, und der Empfang eines weiteren Datagramms von der Benutzerverarbeitung.
Indem zunächst der Empfang eines Datagramms einschließlich eines Bestätigungs-Flag berücksichtigt wird, werden im Schritt 900 alle früher gehaltenen Nachrichten bis hin zur Bestätigungs-sequenznummer verworfen, da die Bestätigung der letzten erhaltenen Nachricht bedeutet, daß die früher übertragenen Datagramme nicht länger gespeichert bleiben müssen. Im Schritt 905 wird der vorher eingestellte Zeitgeber und auch eine Versuchszählung, die bei der Bestimmung von ausgefallenen Adressen in der Adressenliste verwendet wurde, in Bezug auf den speziellen Knoten zurückgesetzt.
Im Schritt 910 wird bestimmt, ob weitere Datagramme in der gesendeten Schlange vorhanden sind und ob nicht im Schritt 915 eine Überprüfung durchgeführt wird, um festzustellen, ob alle früher übermittelten Datagramme bestätigt wurden. Wenn alle früher erhaltenen Datagramme bestätigt worden sind und keine weiteren Datagramme zu senden sind, gibt das RDP-Modul 50 den Ruhezustand ein, und wartet auf weitere Aktivitäten vom Benutzer oder vom Empfangsende.
Wenn bei Schritt 910 weitere Datagramme in der gesendeten Schlange vorhanden sind, wird im Schritt 920 festgestellt, ob das nächste zu sendende Datagramm in das vorher eingestellte Fenster (N) fällt. Wenn es innerhalb der zulässigen Zahl ausstehender Bestätigungen liegt, wird, wie hier beschrieben ist, eine Nachrichten-Kopfzeile gebildet und die letzte Nachricht wird für eine Übertragung ins Netzwerk zum UDP-Modul 41 gesendet. Das System kann nun prüfen, ob weitere Datagramme zu senden sind.
Bei Empfang eines neuen Datagramms im Schritt 935 von einer der Benutzerverarbeitungen, wird das empfangene Datagramm der Schlange zu sendender gespeicherter Nachrichten hinzugefügt. Das Verfahren ist dann das oben für Schritt 920 in Bezug auf weitere, zu übertragende Datagramme beschriebene.
Wenn während dem Warten auf eine Bestätigung vom Empfangsende die durch Zeitablauf bedingte erneute Übertragung erfolgt, dann wird das älteste gespeicherte Datagramm, das das früheste noch nicht bestätigte Datagramm ist, im Schritt 940 zurückgewonnen und der Bestimmungsknotenadresse in der Adressenliste, die zur Sendung des Datagramms verwendet wird, als betriebsunfähig markiert, wenn die Zahl der Versuche, Datagramme unter Verwendung der speziellen Adresse zu senden, überschritten wurde (Schritt nicht gezeigt). Im Schritt 945, wenn eine Datagramm-Übertragungsversuch-Zählung in Bezug auf das spezielle Datagramm überschritten ist, kann angenommen werden, da mehrere oder alle Adressen in der Adressenliste die angeforderte Bestimmung versucht haben, daß diese nicht funktioniert. Das führt zur Rücksendung einer Fehlermeldung zur Benutzerverarbeitung mit allen folgenden, noch nicht gesendeten Datagrammen. Unter der Annahme, daß die Versuchszählung nicht zu einer Überschreitung geführt hat, wird im Schritt 950 die Versuchszählung durchgeführt und es wird im Schritt 955 ein weiterer Versuch zur Sendung des ältesten Datagramms an eine andere Adresse in der Adressenliste unternommen.
Eine weitere, ins Einzelne gehende Beschreibung des Ruhezustands wird für die Realisierung der Erfindung nicht als notwendig angesehen, außer daß anzumerken ist, daß bei Empfang eines gültigen Datagramms von einer Benutzerverarbeitung das RDP-Modul 50 zu Schritt 935 zurückkehrt und das Datagramm, wie oben beschrieben, sendet.
Bezüglich des Zustands 100 "Warte auf Bestätigung der festgelegten Sequenz", gibt das System bei Empfang einer Bestätigung der eingestellten Sequenz in der gleichen Weise, wie in den Schritten 805 bis 860 in 8 beschrieben, den Zustand 90 "Warte auf Bestätigung" ein. Wenn alternativ dazu, wie für das Beispiel im Schritt 840 von 8 festgestellt, eine Negativ-Bestätigung signalisiert wird, oder infolge eines Zeitablaufs, der in der Weise stattfindet, wie für die Schritte 740 bis 745 in 7 beschrieben, veranlaßt das festgelegte Sequenz-Bestätigungssystem eine Zurücksetzung des Systems und beginnt mit dem Zustand "Warte mit dem Senden eines festgelegten Sequenzzustands".
In 6 ist die Seite der Empfangseinheit des RDP-Moduls 50 von 3 anfangs im Zustand 200 "Warte auf festgelegte Sequenz". Unter weiterer Bezugnahme auf 10 veranlaßt der Empfang eines Datagramms vom UDP-Modul 41, in dem das Bit "S" des FL-Feldes gesetzt ist, das Modul, von diesem Zustand zur Prüfung des erhaltenen Datagramms überzugehen.
Im Schritt 210 wird die in der RDP-Kopfzeile 63 gehaltene, Sequenznummer 63 gespeichert, und eine weitere Prüfung der Kopfzeile stellt fest, ob der Sendeknoten 10 von 2 befähigt ist, mit mehr als einer einzigen ausstehenden Bestätigung zu operieren. Wenn bei Schritt 215 klar ist, daß mehrere ausstehenden Datagramme zulässig sind, wird im Schritt 220 die maximale Zahl der ausstehenden Datagramme, mit dem der Empfangsknoten 12 operieren kann, aus einem Speicher wiedergewonnen und im Schritt 225 wird dieser Wert zum Nachrichtenteil eines RDP-Datagramms übertragen, das Bestätigungs-Bit wird freigegeben und das eingestellte Bit der Kopfzeile 63 Flag-Feld FL wird eingestellt und die Sequenznummer wird gelöscht, um dem Sendeknoten anzuzeigen, daß dieses eine Anforderungsnachricht "Stelle Fenster ein" ist. Im Schritt 230 wird nun das Datagramm zum UDP-Modul 41 für eine Übertragung zum Internet-Netzwerk übertragen.
Im Schritt 235 wird ein Zeitgeber gestartet, wobei dieser Zeitgeber auf die Bestätigungsfenstergröße mal der erwarteten schlechtesten Schleifenzeit zwischen Sendeknoten 10 und Empfangsknoten 12 eingestellt wird. Das Modul 50 gibt nun den Zustand 300 "Warte auf Bestätigung Fenster eingestellt" ein.
Wenn nun im Schritt 215 festgestellt wird, daß der Sendeknoten 10 nicht befähigt ist, mit einem Gleitfenster-Protokoll zu arbeiten, wird im Schritt 240 das empfangene Fenster eingestellt, um sicherzustellen, daß keine ausstehenden, nicht bestätigten Datagramme erlaubt sind, und das bestätigte Fenster wird eingestellt, um sicherzustellen, daß alle Datagramme beim Empfang der Reihe nach bestätigt werden.
Nun wird im Schritt 250 ein Datagramm erstellt, in dem das Bestätigungs-Bit gesetzt wird, aber die Fenster-Einstellungs-Bestätigung nicht angefordert ist. Das zurückgesandte Datagramm enthält daher die Sequenznummer als gespeichert und empfangen, das Bit "A" ist gesetzt und das Bit "S" ist auf Null, und das Datagramm wird wiederum im Schritt 255 zum Protokoll-Modul 41 des Benutzer-Datagramms übertragen und die Empfangsseite des RDP-Moduls 50 gibt bis zum Empfang weiterer Datagramme den Ruhezustand ein.
In 10, beim Zustand 200 "Warte auf festgelegte Sequenz", führt schließlich der Empfang eines ungültigen Datagramms zu einer Fehlernachricht, die mit einer Negativ-Bestätigung zurückgesandt wird, wobei im Schritt 260 das Bit "N" zusammen mit der erhaltenen Sequenznummer für eine Zurücksendung im Schritt 265 mit Hilfe des Benutzer-Datagramm-Protokolls verwendet wird. In diesem Fall bleibt das RDP- Modul 50 im Ursprungszustand, das heißt, dem Zustand 200 "Warte auf festgelegte Sequenz".
Unter erneuter Bezugnahme auf 6 wartet das RDP-Modul 50 von 3 im Zustand 300 "Warte auf Bestätigung Fenster eingestellt" auf eine Bestätigung der Nachricht "Fenstergröße eingestellt", die vorher bei Schritt 230 gesendet wurde. Wurde die Bestätigung vom Modul erhalten, wobei aber ein anderer Wert N im Datagramm gespeichert ist und das Bit "S" eingestellt wurde, dann wird die erhaltene Fenstergröße auf den neuen Wert N eingestellt und eine Bestätigung "Sequenz festgelegt" erfolgt in der gleichen Weise, wie in den Schritten 250 und 255 von 10, bevor das RDP-Modul den Ruhezustand zum Warten auf den Empfang eines weiteren Datagramms eingibt, wobei eine Nachricht vom Sendeknoten zurückgesandt wird.
Alternativ dazu kann das RDP-Modul, wenn der im Schritt 235 eingestellte Zeitgeber abläuft, zum Zustand 200 "Warte auf festgelegte Sequenz" zurückgesetzt werden, oder, wenn erneut eine Sequenzfestlegungs-Aufforderung erhalten wird, wird die Prozedur, die im Schritt 210 der 10 beginnt, wiederholt.
Im Ruhezustand 400 erfolgt der Ausstieg mit Hilfe eines Datagramms aus dem Netzwerk. Gemäß 11 ist es bei Empfang eines Datagramms der erste Schritt, die Nachrichten-Sequenznummer aus der Kopfzeile 63 zu erhalten. Daher wird im Schritt 405 die Sequenznummer aus der Kopfzeile entfernt und im Schritt 410 verglichen, um sicherzustellen, daß sie sich in dem Bereich (n – s) bis ((n + s) – 1) befindet, wobei n das empfangene Bit mit der niedrigsten Sequenznummer ist, das noch nicht bestätigt wurde, und s die Anzahl der Datagramme, die das Sendemodul senden kann, ohne daß es eine Bestätigung erhält. Das erfolgt im Schritt 410; wenn aber die Nachrichten-Sequenznummer außerhalb des Bereiches liegt, dann wird das Datagramm verworfen und das Modul 50 bleibt im Ruhezustand. Unter der Annahme, die Sequenznummer liegt innerhalb des Bereichs, erfolgt im Schritt 415 eine Überprüfung, ob in der Tat ein Datagramm-Doppel ausgegeben wurde. Wenn also die erhaltene Nachrichten-Sequenznummer mit einer früher erhaltenen Nachrichten-Sequenznummer identisch ist, bedeutete das, daß die für das Datagramm relevante Bestätigung nicht vom Sendeknoten 10 erhalten worden ist und daß im Schritt 415 erneut eine Bestätigung gesandt wurde.
Wurde im Schritt 415 festgestellt, daß es sich nicht um ein Datagramm-Doppel handelt, wird im Schritt 430 geprüft, um sicherzustellen, daß zur Bestimmungsadressen-Schlange nur Nachrichten mit Sequenznummer übertragen wurden. Wenn daher alle früheren numerierten Nachrichten erhalten und, wie im Schritt 430 angegeben, zur Bestimmungsadressen-Schlange übertragen wurden, und wenn im Schritt 435 festgestellt wird, daß immer noch Raum vorhanden ist, daß diese Nachricht in der Operations-Schlange für den speziellen Port gespeichert wird, wird die Nachricht im Schritt 440 geliefert und der Zustand "Warte mit dem Senden der Bestätigung" wird eingegeben.
Wenn jedoch ein Datagramm vermißt wird, das heißt, wenn in der Sequenznumerierung eine Lücke auftritt, wird das erhaltene Datagramm zwischenzeitig im Schritt 450 gespeichert und es wird ein Zustand "Warte auf vermißte Nachricht" eingegeben. Wenn andererseits die Port-Schlange im Schritt 435 voll ist, was darauf hinweist, daß die Verarbeitung der Bestimmungsadresse die Nachrichten nicht ausreichend schnell bearbeiten konnte, wird im Schritt 460 die Nachricht in einem Zwischenspeicher gehalten. Im Schritt 465 wird ein Lieferversuchs- Zähler eingestellt und das System gibt einen Zustand ein: "Warte mit der erneuten Übertragung, bis Platz in der Port-Schlange ist".
Es wird nun auf 12 Bezug genommen: Wenn während des Zustands "Warte mit dem Senden der Bestätigung" vom UDP-Modul 41 ein weiteres Datagramm erhalten wird, wird gemäß der Prozedur der Nachrichtenbehandlung von 11 vorgegangen. Nach dieser Prozedur der Nachrichtenbehandlung stellt das RDP-Modul 50 im Schritt 510 fest, ob die maximal zulässige Zahl an Datagrammen, die ohne Bestätigung erhalten werden kann, erhalten wurde. Wurde die Höchstzahl der nacheinander erhaltenen Datagramme ohne Bestätigung zu diesem Zeitpunkt nicht erhalten, bleibt das Modul im stabilen Zustand "Warte mit dem Zurücksenden einer Bestätigung". Ist aber die Zahl der Datagramme, die gemäß Schritt 510 ohne Bestätigung erhalten werden kann, erreicht worden, oder wenn im Zeitgeber die auf den Empfang des ersten nicht bestätigten Datagramms eingestellte Zeit abläuft, während sich das Modul im stabilen Zustand befindet, wird im Schritt 515 eine Bestätigung an den Sendeknoten gesandt, gefolgt von Schritt 520 bzw. 525 durch eine Einstellung der Werte des Empfangs- und Bestätigungsfensters.
Es ist hier anzumerken, daß die Datagrammablauf-Steuerung im Sende- und Empfangsknoten von drei Fenstergrenzen gesteuert wird, wobei es sich bei der Einrichtung, die sich im Sendezustand befindet, um ein Sendefenster und bei der Einrichtung, die sich im Empfangszustand befindet, um ein Empfangs- und Bestätigungsfenster handelt. Das Sendefenster in der Einrichtung im Sendezustand begrenzt die Anzahl der Datagramme, die noch ausstehend sein können, das heißt, Datagramme, die gesendet, aber noch nicht bestätigt wurden. Wenn die Datagramme bestätigt wurden, werden sie aus der Sendeschlange gestrichen, und das Sendefenster wird gemäß der Sequenznummer eingestellt, wodurch wei tere Datagramme gesendet werden können. Es ist anzumerken, daß das Sendefenster nicht größer als das Empfangsfenster ist.
Das Empfangsfenster begrenzt die Anzahl der Datagramme, die erhalten und gespeichert werden können, das heißt, die vom RDP-Modul 50 zusammengestellt werden können, und begrenzt daher die Anzahl der Datagramme, die nach einem vermißten Datagramm erhalten werden können. Das Bestätigungs-Fenster begrenzt die Anzahl der Datagramme, die in der Reihenfolge erhalten und in der Empfangsschlange vor dem Versand einer Bestätigung gespeichert werden können.
In 13 überträgt nun das System im Zustand 600 "Warte mit der erneuten Übertragung" wenn die Bestätigungszeit abläuft, oder, wenn, wie im Schritt 605 angegeben, eine Nachricht, die die Sequenznummer einer Nachricht enthält, die bereits erhalten wurde, erneut empfangen wird, eine Nachricht über eine spezielle Mitteilung an den Sendeknoten, die angibt, daß Datagramme bis zu einer Bestätigung oder einer Negativ-Bestätigung nicht erneut gesendet werden sollen, da die Empfangsverarbeitung 31 bis 3p ein früheres, in der Schlange befindliches Datagramm nicht behandelt, es sei denn, daß im Schritt 605 ein gültiges Datagramm erhalten wird; dieses wird dann bis zur Lieferung im Zwischenspeicher gespeichert.
Der dritte Zustand tritt ein, wenn die Zeit für die erneute Lieferung abläuft, dann wird im Schritt 620 die Verarbeitungsschlange überprüft, und wenn diese nicht mehr voll ist, wird im Schritt 625 der Versuch unternommen, das älteste ausstehende Datagramm in die Benutzerverarbeitungs-Schlange zu übertragen. Nachdem im Schritt 630 das älteste Datagramm übertragen wurde, erfolgt eine Überprüfung, um festzustellen, ob weitere Datagramme vorhanden sind, die auf die Lieferung war ten, und, wenn das nicht der Fall ist, und unter der Voraussetzung, daß alle früher erhaltenen Datagramme bestätigt worden sind, gibt das RDP-Modul den Ruhezustand ein.
Wird im Schritt 630 festgestellt, daß weitere Datagramme für eine Sendung zur Verfügung stehen, dann werden über die Schleife der Schritte 620, 625, 630 Versuche zur Übertragung weiterer Datagramme unternommen.
Wird aber im Schritt 620 festgestellt, daß die Schlange voll ist, vorausgesetzt, daß die Versuchszählung nicht den maximalen Wert ergeben hat, wird im Schritt 645 der Zeitgeber für eine erneute Lieferung gestartet.
Wird bei der Abfrage der Versuchszählung festgestellt, daß die Zahl der Versuche, die unternommen worden sind, um zur Schlange zu liefern, anzeigt, daß die Benutzerverarbeitung ausgefallen ist, wird im Schritt 650 eine Negativ-Bestätigung versandt und das System wartet auf eine Bestätigung der übertragenen Negativ-Bestätigung.
Der Zustand "Warte auf vermißte Datagramme", der von einer Reihe von Zuständen eingegeben werden kann, bei denen das letzte erhaltene Datagramm als nicht in der Reihenfolge befindlich gekennzeichnet wurde folgt effektiv der Sequenz der in 11 gezeigten Schritte bis zu dem Zeitpunkt, an dem sich alle Datagramme in der richtigen Reihenfolge befinden.
Um Zweifel auszuräumen, ist anzumerken, daß zu einem beliebigen Zeitpunkt, wenn die Aufforderung "Lege Sequenz fest" erhalten wird, noch ausstehende Datagramme ignoriert werden und eine erneute Initialisierung der Kommunikation zwischen dem Sendeknoten und dem Emp fangsknoten erfolgt. Es ist weiter zu anzumerken, daß es – außer bei einem Ausfall des gesamten Netzwerkes – unwahrscheinlich ist, daß ein Aufforderungssignal gesandt wird: "Wiederhole festgelegte Sequenz", wenn eine Kommunikation einmal zwischen zwei der Knoten eingerichtet worden ist.

Claims

Verfahren zur Übertragung von Datenpaketen zwischen Verarbeitungen, die in einer Multiprozessor-Umgebung des Typs ablaufen, der mehrere Hauptrechner (1nD, 10–1n) umfaßt, wobei auf jeden Hauptrechner an mehreren Netzknotenadressen (5, 7, 10a–1D) zugegriffen werden kann, und das die folgenden Schritte umfaßt: – Erstellen einer Hauptrechner-Bestimmungskennung (61) und eines Hauptrechner-Bestimmungs-Ports (62) für jede zu adressierende Verarbeitung (31-31p), – Erstellen einer Adressenliste für jede Hauptrechner-Bestimmungskennung (61), die für jede Übertragung eines Datenpakets (40) mehrere entsprechende Netzknotenadressen (10A–C, 1nA–1nD) enthält, – zyklisches Auswählen einer Netzknotenadresse aus der jeweiligen Adressenliste für den Hauptrechner-Bestimmungs-Port, die in der für die Übertragung zwischen den Knoten verwendeten Liste die nächste Adresse ist, bis zur letzten Adresse, und – Hinzufügen einer Kopfzeile (63) zum Datenpaket, die die ausgewählte Netzknotenadresse und den Bestimmungs-Port vorgibt, gekennzeichnet durch – Überwachung der Rückdaten zur Paketbestätigung und zur erneuten Übertragung eines beliebigen, nicht bestätigten Datenpakets zur nächsten Netzknotenadresse in der Adressenliste.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 1, das ferner dadurch gekennzeichnet ist, daß jede zwischen den Verarbeitungen gesendete Nachrichten-Kopfzeile (63) eine Nachrichten-Sequenznummer (SEQ) aufweist, die vom Sendeknoten inkrementiert wird, damit der Empfangsknoten das Fehlen einer oder mehrerer Nachrichten in einer Nachrichtensequenz erkennen kann.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 2, das ferner dadurch gekennzeichnet ist, daß der Sendeknoten die Sequenznummer (SEQ) nach Empfang einer Bestätigung vom Empfangsknoten inkrementiert.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 2 oder 3, das ferner dadurch gekennzeichnet ist, daß der Empfangsknoten die letzte empfangene Sequenznummer (SEQ) aufzeichnet und nach Empfang eines Datenpakets, das die richtige Sequenznummer enthält, eine Bestätigung zum Sendeknoten zurücksendet und dessen Sequenznummer inkrementiert.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 4, das ferner dadurch gekennzeichnet ist, daß nach Erfassung einer falschen Sequenznummer (SEQ, die um Eins unter der richtigen Sequenznummer liegt, der Empfangsknoten eine Bestätigung zum Sendeknoten zurücksendet.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 4 oder 5, das ferner dadurch gekennzeichnet ist, daß beim Fehlen einer richtig erhaltenen Sequenznummer (SEQ) der Empfangsknoten eine Nachricht zurücksendet, die die erhaltene Sequenznummer (SEQ) mit einem Flag (N) enthält, das anzeigt, daß ein Datenpaket erhalten wurde, das sich nicht in der Reihenfolge befindet.
Verfahren zur Übertragung von Datenpaketen nach einem der Ansprüche 1 bis 6, das ferner dadurch gekennzeichnet ist, daß die Kopfzei le eine Stücknummer (FRAG) aufweist, die anzeigt, daß das übertragene Datenpaket nur ein Teil des kompletten, zwischen der Sende- und der Empfangsverarbeitung zu übertragenden Datenpakets ist, und der Empfangsknoten die Stücke des kompletten Datenpakets aus einer Anzahl übertragener Datenpakete für eine Übertragung zur Empfangsverarbeitung erneut zusammensetzt.
Verfahren zur Übertragung von Datenpaketen nach einem der vorhergehenden Ansprüche, das ferner dadurch gekennzeichnet ist, daß eine beliebige Netzknotenadresse in der jeweiligen Adressenliste, die Datenpaketausfälle aufweist, die über einer vorgegebenen Anzahl liegen, aus der Adressenliste gestrichen wird.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 8, das ferner dadurch gekennzeichnet ist, daß in regelmäßigen Zeitabständen mehrere Versuche unternommen werden, um eine Verbindung zu den gestrichenen Netzknotenadressen herzustellen.
Verfahren zur Übertragung von Datenpaketen nach einem der Ansprüche 2 bis 6, das ferner dadurch gekennzeichnet ist, daß bei Erkennung des Fehlens einer Nachricht in einer Nachrichtensequenz der Empfangsknoten die Bestätigung vom Sendeknoten zurückhält.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 10, das ferner dadurch gekennzeichnet ist, daß beim Fehlen einer Bestätigung innerhalb eines vorgegebenen Zeitraums der Sendeknoten die erneute Übertragung eines beliebigen, vorher gesendeten Datenpakets veranlaßt, für das vorher noch keine Bestätigung erhalten wurde.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 2 oder 3, das ferner dadurch gekennzeichnet ist, daß der Empfangsknoten mehrere Datenpakete vom Sendeknoten erhält und eine Bestätigung entweder nach Empfang einer vorgegebenen Anzahl von Datenpaketen oder nach Ablauf eines vorgegebenen Zeitraums sendet, je nachdem, was zuerst zutrifft.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 12, das ferner dadurch gekennzeichnet ist, daß beim Empfang einer Bestätigung, die eine bestimmte Nachrichten-Sequenznummer trägt, der Sendeknoten feststellt, daß alle früheren numerierten Datenpakete erhalten wurden.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 13, das ferner dadurch gekennzeichnet ist, daß beim Empfang eines Datenpakets, das eine Nachrichten-Sequenznummer trägt, die nicht der Sequenz entspricht, der Empfangsknoten das Datenpaket speichert, bis alle früheren numerierten Datenpakete erhalten wurden, bevor er eine Bestätigung für das Datenpaket absendet.
Verfahren zur Übertragung von Datenpaketen nach Anspruch 14, das ferner dadurch gekennzeichnet ist, daß, wenn die Nachrichten-Sequenznummer des Empfangsknotens des letzten erhaltenen Datenpaketes um eine vorgegebene Zahl höher als die niedrigste Nachrichten-Sequenznummer einer noch nicht erhaltenen Nachricht ist, der Empfangsknoten eine Bestätigung des letzten erhaltenen Datenpakets überträgt, das die höchste Nachrichten-Sequenznummer hat.