DE69026400T2

DE69026400T2 - System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von Datenverarbeitungssystemen

Info

Publication number: DE69026400T2
Application number: DE69026400T
Authority: DE
Inventors: Gary Lewis Owens
Original assignee: International Business Machines Corp
Current assignee: Cisco Systems Inc
Priority date: 1989-01-31
Filing date: 1990-01-24
Publication date: 1996-10-10
Anticipated expiration: 2010-01-25
Also published as: JPH02235462A; JPH0626360B2; EP0381365B1; EP0381365A3; DE69026400D1; US5142622A; EP0381365A2

Description

System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von Datenverarbeitungssystemen
Die vorliegende Erfindung bezieht sich allgemein auf ein Netzwerk von Datenverarbeitungssystemen und insbesondere auf die Verbindung von Datenverarbeitungssystemen in unterschiedlichen Netzwerkprotokollbereichen, beispielsweise die unterschiedlichen Netzwerkprotokollbereiche SNA und TCP/IP.
Ein System mit mehreren Bereichen besitzt mindestens ein Datenverarbeitungssystem, das mit mindestens zwei verschiedenen Datenverarbeitungssystemen in mindestens zwei unterschiedlichen Netzwerkprotokollbereichen, das heißt Netzwerkprotokollarchitekturen, verbunden ist. Das Schwierige bei mehreren Bereichen ist die Kommunikation zwischen Maschinen, die an einen anderen Netzwerktyp angeschlossen sind. Zum Beispiel kann ein Datenverarbeitungssystem unter Verwendung von SNA LU 6.2 als Netzwerkprotokoll nicht automatisch mit einem anderen Datenverarbeitungssystem unter Verwendung von TCP/IP als Netzwerkprotokoll kommunizieren. Sowohl SNA LU 6.2 als auch TCP/IP sind Beispiele für Stromprotokolle, wobei Daten als ein Strom mit unbestimmter Länge fließen und die Bytes in der richtigen Reihenfolge geliefert werden. Das Problem besteht darin, einen Strom von Bytes von einem Datenverarbeitungssystem, das ein einigermaßen äquivalentes Protokoll verwendet, zu einem anderen Datenverarbeitungssystem, das ebenfalls ein einigermaßen äquivalentes Protokoll verwendet, beispielsweise das Stromprotokoll dieses Beispiels, wobei jedoch die beiden Protokolle nicht exakt die gleichen sind, zum Beispiel SNA LU 6.2 und TCP/IP, zu leiten.
Bekanntermaßen löst es das obige Problem auf der Ebene des Anwendungsprogramms. Ein Anwendungsprogramm, das auf einem Datenverarbeitungssystem an einem Ende der Verbindung läuft, kann so ausgelegt werden, daß es ein bestimmtes Netzwerkprotokoll verwendet. In diesem Fall ändert es bekanntlich die Anwendung, um über ein anderes Protokoll arbeiten zu können. Dies erfordert eine nicht unwesentliche Änderung des Quellprogrammcodes der ursprünglichen Anwendung. Je nach dem, wie das ursprüngliche Anwendungsprogramm ausgelegt war, sind hierfür unter Umständen eine Vielzahl an Änderungen des Programmcodes nötig.
Es löst bekanntlich auch das obige Problem durch Implementierung desselben Protokolls auf beiden Maschinen. Um beispielsweise eine SNA-Transaktionsanwendung, die in einem SNA-Netzwerk läuft, verwenden zu können, um Transaktionen unter Verwendung eines TCP-Netzwerks in Datenverarbeitungssysteme einarbeiten zu können, könnte man diese Transaktionsanwendung in TCP reimplementieren, indem man daraufhin TCP auf dem Datenverarbeitungssystem des Client, IP in SNA und zwischen beiden ein Gateway implementiert. Das Datenverarbeitungssystem des Chent kann anschließend unter Verwendung von TCP/IP implementiert werden. Das Problem bei dieser Vorgehensweise besteht darin, daß man die Anwendung reimplementieren muß, um an einem oder am anderen Ende des Netzwerks das unterschiedliche Protokoll verwenden zu können. Dies ist besonders dann aufwendig, wenn die Anwendung umfangreich und komplex ist.
Es gibt manche Protokolle auf Anwendungsebene, die auf SNA eine Handshake-Operation durchführen, beispielsweise 3270 SNA. Diese besitzen ihr eigenes Datenformat mit Meta-Daten im Datenstrom. Es gibt andere Protokolle auf Anwendungsebene, beispielsweise Telnet in TCP, die nach vorn und nach hinten sprechen und Meta-Daten und Daten im Datenstrom besitzen. Man kann jedoch diese beiden Protokolle nicht dazu bringen, daß sie miteinander sprechen, da sie unterschiedliche Daten und Meta-Daten in ihren Datenströmen besitzen.
Wenn eine Anwendung ein Protokoll verwenden würde und diese Anwendung auf einem Datenverarbeitungssystem mit einem unterschiedlichen Protokoll laufen sollte (wenn das Datenstromformat bekannt ist), könnte man die Client-Hälfte der Anwendung unter Verwendung des anderen Protokolls in das Datenverarbeitungssystem schreiben.
Um also die Anschlußmöglichkeiten des Netzwerks zu erweitern, wird die Anwendung bekanntlich reimplementiert, um das unterschiedliche Protokoll verwenden zu können, ein Protokoll auf ein anderes aufgesetzt und zwischen beiden ein Gateway gesetzt. Bekanntlich wird auch ein größeres Netzwerk zusammengestellt, das durch Replikation und Duplikation jeden Protokolltyp verwendet.
Ein Artikel von T. J. Routt mit dem Titel "SNA to OSI: IBM building upperlayer gateways", veröffentlicht in Data Communications, Band 16, Nr. 5, Mai 1987, Seiten 120-142, beschreibt das Verhältnis zwischen der SNA-Architektur von IBM und der OSI-Architektur (Open Systems Interconnection), und stellt mehrere Produkte vor, die entwickelt wurden, um eine Kommunikation zwischen den beiden Architekturen zu ermöglichen. Ein Artikel von R. Martinez et al mit dem Titel "Interconnection of Sytek LocalNet 20 Networks through the Defense Data Network using Internet Protocol Gateways", Sechste Jährliche Internationale Konferenz über Computer und Kommunikation in Phoenix, Februar 1987, Seiten 354-360, beschreibt die Auslegung eines generischen Gateways zwischen LANS und dem Defense Data Network (DDN).
Der Begriff "Anschlußstelle" bezeichnet eine Schnittstelle eines Anwendungsprogramms, die für die Berkeley-Version des Betriebssystems UNIX von AT&T (UNIX und AT&T sind Warenzeichen der American Telephone and Telegraph Company) entwickelt wurde, um Anwendungen, die in einem Netzwerk auf Datenverarbeitungssystemen laufen, miteinander zu verbinden. Die Bezeichnung Anschlußstelle wird verwendet, um ein Objekt zu definieren, das in einem Netzwerk einen Kommunikationsendpunkt identifiziert. Eine Anschlußstelle kann mit anderen Anschlußstellen verbunden werden. Die Daten können über das zugrunde liegende Protokoll der Anschlußstelle in eine Anschlußstelle laufen und so geleitet werden, daß sie an einer anderen Anschlußstelle erscheinen. Eine Anschlußstelle verbirgt das Protokoll der Netzwerkarchitektur hinter einer tieferen Ebene. Diese tiefere Ebene kann ein Stromverbindungsmodell (virtueller Kreis), ein Datagram-Modell oder ein anderes Modell sein.
Ein Stromverbindungsmodell bezieht sich auf eine Datenübertragung, in der die Datenbytes nicht durch eine Aufzeichnung oder Markierung getrennt sind. Ein virtueller Kreis impliziert, daß scheinbar ein Kommunikationsendpunkt vorhanden ist, der mit einem anderen Kommunikationsendpunkt verbunden ist. Sobald die Verbindung aufgebaut ist, können nur diese beiden Endpunkte miteinander kommunizieren.
Anschlußstellen werden nach Bereich (Adressenfamilie oder Netzwerktyp) und Modelltyp (Strom, Datagram usw.) unterschieden. Falls erforderlich, kann die Anschlußstelle weiter nach Protokolltyp oder Subtyp spezifiziert werden. Der Bereich gibt das verwendete Adressierungskonzept an. Beispielsweise gibt es einen Internet-IP-Bereich und auch einen SNA-Bereich für Netzwerke, die TCP bzw. SNA verwenden. In diesem Dokument bezieht sich die Bezeichnung "Bereich" auf die Adressenfamilie einer Anschlußstelle und nicht auf einen bereichsnennenden Bereich. Ein bereichsnennender Bereich ist ein Konzept einer miteinander verbundenen Gruppe hierarchischer Adressen, in der jeder Adreßteil durch einen Begrenzer, beispielsweise einen Punkt, getrennt ist.
Da eine Anschlußstelle durch einen Bereich spezifiziert ist, sind für Anschlußstellen keine Verbindungen zwischen unterschiedlichen Bereichen möglich. Das bedeutet, daß wenn ein Anwendungsprogramm im Internet-(Darpa)Bereich eine Anschlußstelle erzeugt, diese nur mit Anschlußstellen im selben Bereich verbunden werden kann. Hinweis: "Darpa" wird verwendet, um anzugeben, daß Internet, ein Kurzwort für Internetworking, in diesem Dokument nicht nur verwendet wird, um allgemein die Internet-Ebene einer bestimmten Protokollfamilie, die Mittel zur Weiterleitung, Routing-Steuerung und Verarbeitungssteuerung usw. enthält, anzugeben, sondern auch als Name für eine bestimmte Implementierung eines Internets, dem Internet, dem Darpa Internet oder dem Arpa Internet. Ein anderer Name für diese Internet-Ebene ist Internet-Protokoll (IP). TCP/IP wird ebenfalls häufig verwendet, um dieses Protokoll zu bezeichnen.
Ursprünglich war die Anforderung, daß eine Anschlußstelle nur mit Anschlußstellen desselben Bereichs verbunden werden kann, eine begründete Einschränkung. Dadurch konnte der Programmcode vereinfacht werden, wenn ohnehin nur ein wirklich nützlicher Bereich vorhanden war. Mit dem Aufkommen weiterer Bereiche (insbesondere SNA) wurden Verbindungen über mehrere Bereiche hinweg wünschenswert. Zum Beispiel ermöglichten Verbindungen über mehrere Bereiche hinweg den Anwendern, Mail über mehrere Bereiche hinweg zu transportieren. Auch ermöglichten Verbindungen über mehrere Bereiche hinweg, daß Programme unter Verwendung bestehender Kommunikationsnetzwerke kommunizieren konnten.
Unter einem Gesichtspunkt stellt die vorliegende Erfindung ein System zur Kommunikation zwischen einem ersten Datenverarbeitungssystem in einem ersten Netzwerkbereich und einem zweiten Datenverarbeitungssystem in einem zweiten Netzwerkbereich bereit, wobei der genannte erste Netzwerkbereich eine Netzwerkprotokollarchitektur besitzt, die sich vom genannten zweiten Netzwerkbereich unterscheidet, wobei das genannte System mindestens ein Kommunikationsendpunktobjekt in einer Ebene des genannten ersten Datenverarbeitungssystems im genannten ersten Netzwerkbereich und mindestens ein Kommunikationsendpunktobjekt in einer Ebene des genannten zweiten Datenverarbeitungssystems im genannten zweiten Netzwerkbereich umfaßt, wobei das System charakterisiert ist durch: ein Verbindungsmittel, das unabhängig von einem Anwendungsprogramm ist, das auf einem der beiden genannten Datenverarbeitungssysteme läuft, um automatisch auf der genannten Ebene des genannten ersten Datenverarbeitungssystems und auf der genannten Ebene des genannten zweiten Datenverarbeitungssystems eine Verbindung zwischen dem genannten ersten Datenverarbeitungssystem und dem genannten zweiten Datenverarbeitungssystem eine Verbindung herzustellen, wobei das Verbindungsmittel ein Routing-Mittel zur Bestimmung eines Leitwegs für die Verbindung zwischen dem genannten ersten und zweiten Netzwerkbereich sowie ein Mittel zur Kommunikation auf der genannten Verbindung zwischen dem genannten ersten Datenverarbeitungssystem und dern genannten zweiten Datenverarbeitungssystem umfaßt.
Darüber hinaus stellt die vorliegende Erfindung ein Arbeitsverfahren gemäß Anspruch 7 bereit.
In bevorzugten Ausführungsbeispielen umfaßt die vorliegende Erfindung weiterhin mindestens ein Kommunikationsendpunktobjekt auf der genannten Ebene eines dazwischenliegenden Datenverarbeitungssystems, wobei jedes Kommunikationsendpunktobjekt zur Kommunikation unter Verwendung entweder der Netzwerkprotokollarchitektur des ersten Netzwerkbereichs oder der Netzwerkprotokollarchitektur des zweiten Netzwerkbereichs angepaßt ist, wobei sich das genannte Verbindungsmittel im genannten dazwischenliegenden Datenverarbeitungssystem befindet und die genannte Verbindung das genannte dazwischenliegende Datenverarbeitungssystem durchläuft.
Die vorliegende Erfindung leitet automatisch eine Verbindung zwischen Datenverarbeitungssystemen mit unterschiedlichen Netzwerkbereichen, und zwar unabhängig davon, ob eine Anwendung auf den Datenverarbeitungssystemen läuft. Das bevorzugte Ausführungsbeispiel beschreibt die Verbindungen zwischen unterschiedlichen Bereichen mit Bezug auf die unterschiedlichen Netzwerkbereiche von TCP (Übertragungssteuerprotokoll) und SNA (Systemnetzwerkarchitektur).
Das Routing wird automatisch auf einer Ebene ausgeführt, die die Kommunikationsendpunktobjekte enthält, wodurch die Implementierung der Kommunikation zwischen mehreren Bereichen vereinfacht wird. Im Betriebssystem AIX (AIX ist ein Warenzeichen der International Business Machines Corporation) und anderen Betriebssystemen, die auf der Berkeley-Version des Betriebssystems UNIX laufen, wird diese Ebene als Anschlußstellenebene bezeichnet.
Ein dazwischenliegendes Verarbeitungssystem wird verwendet, um zwischen einem Verarbeitungssystem, das einen Netzwerkbereich wie beispielsweise TCP verwendet, und einem anderen Verarbeitungssystem, das einen anderen Netzwerkbereich wie beispielsweise SNA verwendet, ein Gateway bereitzustellen. In einer anderen Ausführung kann das Client-Datenverarbeitungssystem unter Verwendung von TCP/IP implementiert werden, das dann in einer Gateway-Anordnung durch Anschlußstellenleitung auf derselben Maschine in einen SNA-Datenstrom geleitet werden kann, ohne daß ein dazwischenliegendes Verarbeitungssystem die Anschlußstellenleitung durchführt.
In jedem Fall enthält die Anschlußstellenebene, die die Anschlußstellenleitung durchführt, Einrichtungen zur automatischen Weiterleitung einer Verbindung über mehrere Bereiche hinweg.
Im Client-Verarbeitungssystem, welches versucht, eine Verbindung herzustellen, wird in einem bestimmten Bereich eine Anschlußstelle geschaffen. Wenn sich die Anschlußstelle in einem anderen Bereich befindet, fällt die Anschlußstelle nicht aus, wenn die Anschlußstellen-Leiteinrichtung der vorliegenden Erfindung implementiert wird. Die Verbindungsfunktion ist so ausgelegt, daß sie die Versuche an einer Verbindung für mehrere Bereiche abfängt. Wird die Herstellung einer Verbindungsfunktion an einer Anschlußstelle in einem anderen Bereich versucht, so wird die Anschlußstellen-Leiteinrichtung der vorliegenden Erfindung aufgerufen.
In einer anderen Ausführung kann eine Funktion Verbinden-Zu implementiert werden, die den Platz der Funktionen Anschlußstelle und Verbinden einnimmt und diese Funktionen kombiniert. Mit der Funktion Verbinden-Zu wird eine Anschlußstelle erst erzeugt, wenn der Leitweg bekannt ist. Dadurch wird der unnötige Aufwand der Erstellung einer Anschlußstelle, die ausfallen kann, und der Ausführung von Funktionen, die das Ergebnis der ausgefallenen Anschlußstelle sind, vermieden. Die Funktion Verbinden-Zu bestimmt, wie eine Verbindung hergestellt werden kann, und erzeugt daraufhin im Bereich, der benötigt wird, um die festgelegte Verbindung herzustellen, eine Anschlußstelle.
Durch jede der oben angeführten Vorgehensweisen läßt sich eine Verbindung zu einer Anschlußstelle in einem anderen Bereich über eine dazwischenliegende Anschlußstelle aufbauen. Wenn von einem Ende der Verbindung Daten an der dazwischenliegenden Anschlußstelle ankommen, sendet die dazwischenliegende Anschlußstelle unverzüglich die Daten an das andere Ende der Verbindung, anstatt die Daten in eine Warteschlange zu stellen, um sie einer Prozeßintervention im dazwischenliegenden Verarbeitungssystem zu unterziehen.
Wenn darüber hinaus die dazwischenliegende Anschlußstelle nach der Adresse des anderen Endes der Verbindung untersucht wird, identifiziert die dazwischenliegende Anschlußstelle den Verbindungshost im Gegensatz zum dazwischenliegenden Host. Auf diese Weise ist die Anschlußstellen-Leiteinrichtung des dazwischenliegenden Hosts für die Hosts an jedem Ende der Verbindung transparent.
Nachfolgend wird beispielhaft ein Ausführungsbeispiel der vorliegenden Erfindung beschrieben, wobei auf die folgenden Begleitzeichnungen verwiesen wird:
Figur 1 ist ein Diagramm, das eine Verbindung zwischen einem Prozeß AA auf Host A und einem Prozeß CC auf Host C darstellt. Das Anschlußstellen-Routing wird verwendet, um die Begrenzung zwischen den Netzwerken des Typs A und des Typs C an Host B zu überschreiten.
Figur 2 ist ein Flußdiagrarnm, welches das Arbeitsszenario von Figur 1 unter Verwendung eines expliziten und eines impliziten Routing.
Figur 3 ist ein Flußdiagramm, das die modifizierten Schritte bei der Durchführung einer Funktion Verbinden 0 zu einem bestimmten Ziel darstellt.
Figur 4 ist ein Flußdiagramm, das die Schritte bei der Schaffung einer Anschlußstelle darstellt, wenn der Host keine Anschlußstelle im angegebenen Bereich besitzt.
Figur 5 ist ein Flußdiagramm, das die an Host B ausgeführten Schritte darstellt.
Figur 6 ist ein Flußdiagramm, das die Schritte einer Funktion Verbinden-Zu ( ) darstellt.
Figur 7 ist ein ausführlicheres Diagramm der Anschlußstellen- Leiteinrichtung der vorliegenden Erfindung.
Die folgende Beschreibung bezieht sich auf eine Architektur zur Leitung virtueller Schaltungen auf der Basis von Anschlußstellen. Zwar werden hierbei Strom-Anschlußstellen miteinbezogen, doch ist die Erfindung nicht auf Stromprotokolle oder auf Anschlußstellen begrenzt. Die Konzepte der vorliegenden Erfindung könnten auf ähnliche Kommunikationsendpunkte angewandt. werden, wie sie auch innerhalb anderer Betriebssysteme verwendet werden.
Wir betrachten nun Figur 1. Ein Prozeß AA, 10, in einem Datenverarbeitungssystem 11, Host A, wünscht eine Verbindung seiner Anschlußstelleneinrichtungen 12 mit dem Prozeß CC, 40, in einem Datenverarbeitungssystem 41, Host C. Das Datenverarbei- tungssystem 11 wird so dargestellt, daß es nur einen bestimmten Bereich von Anschlußstellen AF_A, 13, unterstützt, beispielsweise TCP, und das Datenverarbeitungssystem 41 wird so dargestellt, daß es nur Anschlußstellen unterstützt, die im Bereich der Adreßfamilie C, 43, existieren. Da sich die Benennungskonventionen und die zugrundeliegenden Transportmechanismen zwischen der Adreßfamilie A, 13, und der Adreßfamilie C, 43, unterscheiden, kann ohne eine dazwischenliegende Einrichtung keine Verbindung stattfinden. Die dazwischenliegende Einrichtung ist die Anschlußstellen-Routingeinrichtung 70 in der Anschlußstellenebene 32, die im Datenverarbeitungssystem 31 existiert und als Host B dargestellt ist.
Um die Initiierung einer Verbindung zu beschreiben, läßt sich sagen, daß der Prozeß AA, 10, im Datenverarbeitungssystem 11 über die Anschlußstellen-Programmierschnittstelle eine Verbindung zum allgemeinen Anschlußstellencode, 12, aktiviert, die ihrerseits durch den adreßfamilienspezifischen Anschlußstellencode für AF_A, 13, läuft. Die erforderlichen Daten- und Steuerinformationen werden von den Schnittstellenebenen und den physikalischen Zugriffsebenen 14 bereitgestellt. Die Daten gehen daraufhin auf das Netzwerk 50 und schließlich in das Datenverarbeitungssystem 31, das als Host B dargestellt ist&sub1; und zwar über die Schnittstellenebene 34, und anschließend durch den Code für die Adreßfamilie A, die als AF_A, 36, dargestellt ist.
Zum Vergleich: Das Datenverarbeitungssystem 21, das als Host D dargestellt ist, stellt ein existierendes Internet-Routing innerhalb einer einzigen Adreßfamilie dar, nämlich der Adreßfamilie A, AF_A, 23. Es wird darauf hingewiesen, daß die übergreifende Verbindung innerhalb der Adreßfamilie A, 23, auftritt. Fast jede TCP/IP-Implementierung kann innerhalb ihrer eigenen Adreßfamilie einen Routing-Vorgang durchführen. SNA besitzt vergleichsweise ähnliche Gateway- und Weiterleitungsfunktionen. Die Möglichkeit einer übergreifenden Verbindung, wie sie im Datenverarbeitungssystem 21 dargestellt ist, ist unabhängig vom Modelltyp des Stroms oder des Datagramms. Sie ist lediglich davon abhängig, ob sie sich im selben Netzwerkbereich befindet.
Im Datenverarbeitungssystem 31 gehen die Verbindungsanforderungspakete durch den Schnittstellenebenencode 34 zum Code der Adreßfamilie A, AF_A, 36, durch die allgemeine Anschlußstellenebene 32 und in den Anschlußstellenleitcode 70. Die Anschlußstellenleitcodeeinrichtung 70 ist dort, wo die Adreßabbildung und die übergreifende Verbindung stattfinden. Die Pfeile 37 der übergreifenden Verbindung sind so dargestellt, daß sie in die Anschlußstellenleitebene 70 des Datenverarbeitungssystems 31 gezogen sind, im Gegensatz zu den Pfeilen 27 der übergreifenden Verbindung, die im Adreßfamiliencode 23 des Datenverarbeitungssystems 21 dargestellt sind.
Eine Verbindungsanforderung, die im Anschlußstellenleitcode 70 des Datenverarbeitungssystems 31 erzeugt wird, geht daraufhin durch den Code C der Adreßfamilie, AF_C, 33, und durch den Schnittstellenebenencode 35 für das andere Netz 60, beispielsweise SNA. Die Verbindungsanforderungspakete gehen durch das Netzwerk 60 zum Schnittstellenebenencode 44 bis zum Code der Adreßfamilie C, AF_C, 43, und laufen weiter durch den Code 42 der allgemeinen Anschlußstellenschnittstellenebene, wo die Verbindung registriert wird. Dann kann der Prozeß CC, 40, auf die Verbindungsanforderung reagieren, um die Verbindung zwischen Netzwerken übergreifender Bereiche herzustellen.
Figur 7 zeigt Artikel 70 von Figur 1 in detaillierterer Form. Der Artikel 701 enthält die Programme und Daten zur Steuerung der Anschlußstellenleiteinrichtung. Eine Verbindungsanforderung zur Herstellung eines Anschlußstellenleitwegs trifft an den Anschlußstellen für diesen Dienst ein, nämlich an Artikeln 704 und 705. Die Routing-Agent-Software, Artikel 703, akzeptiert die Verbindung, wodurch eine Datenanschlußstelle erzeugt wird, Artikel 709 - 714. Die Leitweganforderungsmeldung trifft an der Datenanschlußstelle ein, und der Routing-Agent 703 prüft seine Leitwegdatenbank 702 um festzustellen, ob ein Leitweg möglich ist. Ist ein Leitweg möglich, überprüft der Routing Agent 703 seine Leitwegdatenbank 702 um festzustellen, wie ein Leitweg herzustellen ist. Daraufhin erstellt der Routing Agent eine passende Datenanschlußstelle (Artikel 710 für Artikel 709, usw.), und verbindet zum nächsten Schritt. Wenn die Routing-Agent-Software Meldungen für weitere Leitwegschritte empfängt, sendet sie sie über die akzeptierte Datenanschlußstelle zurück zum Anschlußstellenleitweganforderer. Sobald alle Schritte erfolgt sind, erstellt der Anschlußstellenleitwegagent einen Datenübertragungsagent, Artikel 706 bis 708, der sich den Paaren von Datenanschlußstellen anfügt, und leitet die Daten von einer Anschlußstelle zur anderen und umgekehrt.
Das obige Szenario wird im folgenden Programmiersprachcode weiter beschrieben. Die folgenden Ausführungen enthalten Beispiele unter Verwendung von Programmen und Funktionsnamen zur Beschreibung des Funktionsszenarios von Figur 1. Das folgende Funktionsszenario geht von einem Telnet (oder einem ähnlichen Programm) aus, das an ein Fernverarbeitungssystem angeschlossen ist, das durch mindestens eine Bereichsgrenze getrennt ist. Im folgenden werden drei Maschinen verwendet: "Host A" ist über TCP mit "Host_B" verbunden, und "Host_B" ist über SNA mit "Host_C" verbunden.
*/from application view/*
user on host_A says "telnet host_C"
Telnet does a gethostbyname for "host_C"
telnet tries to create a socket for domain of "host_C"
- it fails.
telnet does a getservbyname for sockroute
- it finds (the only) sockroute available in TCP domain
telnet invokes sockroute function to get which domain to initiate the connection in (or to get a route to host_C)
since telnet knows it is now using socket routing it uses the (initial domain and routelist) to
1. create a socket in its initial domain. (TCP)
2. connects to sockaddr of "host_C" telnetd -or "connectto routelist telnetd"
when socket connect succeeds, proceed as any SOCK_STREAM app would
- alternatively ( with connectto ( ) as "full function") user on host_A says "telnet host_C"
telnet does a gethostbyname (or getaddrbyname) for "host_C" - to see if it exists and to get host_C's address
telnet does a "connectto ( host_C:telnetd, SOCK_STREAM) - which gets a connected socket.
Der obige Programmiersprachcode wird unter Bezugnahme auf die Figuren 2 bis 4 ausführlicher beschrieben. Der Begriff "telnet" bezeichnet einen entfernten Terminal-Emulator mit dem Argument "host_C". Dies verbindet den Terminal-Emulator mit einem entfernten Host, der in diesem Fall "host C" ist, Schritt 201, Figur 2. "Gethostbyname" ist ein Funktionsaufruf des telnet-Programms, das die Adressierungsinformationen für den Host C einholt, Schritt 203, Figur 2. Die Adressierungsinformationen für Host C enthalten innerhalb des Bereichs einen Bereich und eine Adresse.
An diesem Punkt läßt sich das Routing entweder explizit oder implizit durchführen. Eine explizite Funktion würde einbeziehen, daß der Benutzercode eine Leitwegfunktion aufruft, wenn der ursprüngliche Versuch, eine Anschlußstelle zu erzeugen, scheitert. Eine implizite Funktion wäre einfach eine Durchführung eines connectto ( ) an der Zieladresse. Beim expliziten Routing liegt der Vorteil in der expliziten Steuerung durch die Anwendung. Die Nachteile sind eine fehlende zentrale Steuerung und ein komplizierterer Benutzercode. Beim impliziten Routing sind die Vorteile und Nachteile genau gegenteilig im Vergleich zu den oben genannten. Beim impliziten Routing sind die Vorteile eine zentrale Steuerung und ein weniger komplizierterer Benutzercode. Beim impliziten Routing liegt der Nachteil darin, daß die Anwendung keine direkte Steuerung zuläßt.
Beim expliziten Routing versucht Telnet, innerhalb dieses Bereichs eine Anschlußstelle zu erstellen, Schritt 204. Wenn der Host keine Anschlußstellen dieses Bereichs besitzt, Schritt 205, schlägt die Erstellung einer Anschlußstelle fehl, Schritt 211. An diesem Punkt ruft die Anwendung Telnet eine Leitwegfunktion auf, Schritt 213, Figur 4, wenn der Anschlußstellenversuch fehlgeschlagen ist, Schritt 211. Besitzt der Host Anschlußstellen innerhalb dieses Bereichs, ist der Anschlußstellenversuch erfolgreich, Schritt 206. Ist der Anschlußstellenversuch erfolgreich, führt die Anwendung ein connect ( ) durch, Schritt 215. Das connect ( ) wird ebenfalls mit Bezug auf Figur 3 gezeigt. Ist das connect ( ) erfolgreich, Schritt 217, Figur 2, geht die Kommunikation zwischen den beiden Prozessen weiter, wie dies in dieser Technologie bekannt ist, Schritt 207.
Ist eine Verbindung im selben Anschlußstellenbereich fehlgeschlagen, dann würde (möglicherweise mit einer eingerichteten Anschlußstellenoption) das Anschlußstellen-Routing aufgerufen werden. Dadurch wird ein implizites Routing bereitgestellt, Figur 3, selbst im Fall einer Verbindung zwischen zwei Bereichen desselben Typs unter Verwendung eines dazwischenliegenden Bereichs eines anderen Typs.
Wie aus der Darstellung in Figur 3 hervorgeht, ermöglicht eine Modifikation der Funktion connect ( ) dieser Funktion, diejenigen Situationen einzufangen, in denen ein Anschlußstellen-Routing benötigt wird, um ein Gateway zwischen zwei gleichen Bereichen unter Verwendung ungleicher Bereiche herzustellen. Wenn eine normale Verbindung, Schritt 301, fehlschlägt, Schritt 303, und dieser Fehler darauf zurückzuführen ist, daß das Zielnetzwerk nicht erreichbar ist, Schritt 307, dann erfolgt ein Versuch eines impliziten Routing. Dies beginnt mit Schritt 311, in dem ein Anschlußstellenleitweg für das Ziel gesucht wird. Wird kein Leitweg gefunden, dann wird ein Fehler gemeldet, Schritt 315. Wird ein Leitweg gefunden, dann wird im ersten Schritt eine Verbindung zum Anschlußstellenleitwegdienst hergestellt, Schritt 317. Danach wird eine Leitweganforderung gesendet, Schritt 319, und die Antworten der Leitweganforderungen werden empfangen, Schritt 321, bis alle Schritte miteinander verbunden werden, Schritt 323. Zu diesem Zeitpunkt wird eine Verbindungsanforderung gesendet, um alle Routers aufzufordern, eine Leitung für die Datenübertragung einzurichten, Schritt 325. Nachdem die Verbindungsantwort empfangen wurde, Schritt 327, wird die Suchadresse des Ziels für die lokale Anschlußstelle eingerichtet, Schritt 329, und eine Erfolgsmeldung geht an den Verursacher dieses connect zurück, Schritt 331.
Wir betrachten nochmals Figur 2. Eine Funktion connectto kann dem generischen Anschlußstellenebenencode hinzugefügt werden, um ein implizites Routing von einer Anwendungsebene aus zu implementieren, Schritt 221, Figur 2. Die Funktion connectto wird anstelle einer Anschlußstellenfunktion und einer Verbindungsfunktion aufgerufen. Die Funktion des Anschlußstellensystemaufrufs und die Funktion der Verbindung werden in der Funktion connectto kombiniert. Der Vorteil dabei liegt darin, daß die Funktion connectto mehr Adressierungsdaten verarbeiten kann. Die Funktion connectto braucht außerdem im Kernel keine Anschlußstelle zu erzeugen, was fehlschlagen könnte und worauf man dann die fehlerhafte Anschlußstelle untersuchen müßte.
Die Anschlußstellenparameter der Funktion connectto würden den Typ und das Protokoll beeinhalten. Da der vorige connect- Aufruf Argumente für den Host-Namen besitzt, würde die Funktion connectto den Namen des Hosts in portierbarerer Form annehmen, beispielsweise den Namen des Hosts in einem Textstrom, während connect den Namen des Hosts in einer Anschlußstellenstruktur annimmt.
Wir betrachten nun Figur 6. Die Funktion connectto ( ) wird ausführlicher beschrieben. Wenn connectto ( ) so implementiert wird, daß es als Argument einen Host-Namen annimmt, dann erhält es die Zieladresse, Schritt 601. Unter Verwendung dieser Adresse überprüft die Funktion die Leitwegtabelle für dieses Ziel, Schritt 603. Wird kein Leitweg gefunden, Schritt 605, dann wird eine Fehlermeldung zurückgesendet, Schritt 607. Wenn sich das Ziel im selben Bereich befindet, und für Gateways keine ungleichen Bereiche erforderlich sind, Schritt 609, dann wird im selben Bereich eine Anschlußstelle erzeugt, Schritt 611. Eine normale Verbindung wird zum Ziel aufgebaut, Schritt 612. Der Leitweg für die Kommunikation ist dann eingerichtet, Schritt 613.
Wenn sich das Ziel nicht im selben Bereich befindet, oder wenn ungleiche Bereiche für die Gateways erforderlich sind, Schritt 609, dann wird im Bereich im ersten Schritt eine Anschlußstelle erzeugt, Schritt 609. Daraufhin wird im ersten Schritt eine Verbindung zum Anschlußstellenleitwegdienst eingerichtet, Schritt 617. Eine Leitweganforderung wird gesendet, und eine Antwort auf die Anforderung wird empfangen, Schritt 621, bis alle Schritte miteinander verknüpft sind, Schritt 623. Danach wird eine Verbindungsanforderung gesendet, Schritt 625, und ihre Antwort wird empfangen, Schritt 627. Der Suchname des Ziels wird für die lokale Anschlußstelle eingerichtet, Schritt 629. Der Leitweg steht nun für normale Kommunikationen bereit, Schritt 613.
Mit den folgenden Modifikationen, die auch als Anschlußstellen-Routing bezeichnet werden, kann die Erstellung einer Anschlußstelle fortgesetzt werden, Schritt 213, wie dies in Figur 4 dargestellt ist, wenn der Host keine Anschlußstelle im angegebenen Bereich besitzt, Schritt 205, Figur 2. Die Modifikationen können auf der Chent-Seite stattfinden, Host_A. Host_C wird als Server bezeichnet.
Die Anwendung Telnet führt eine Funktion "getservbyname" für den Anschlußstellenleitwegdienst aus, Schritt 401, Figur 4. Wenn beispielsweise der Host nur Anschlußstellen im Bereich TCP besitzt, findet telnet den einzigen im Bereich TCP verfügbaren Anschlußstellenleitweg, Schritt 403. Als nächstes verwendet telnet die Funktion sockroute, Schritt 405, um den Leitweg zu bestimmen und um festzulegen, welcher Bereich der Anschlußstelle erstellt werden soll, Schritt 406. Danach wird die Anschlußstelle für den ursprünglichen Schritt des Leitwegs erstellt, Schritt 412, und dann wäre die Verbindung eingerichtet, Schritt 413. An dieser Stelle kann die Anwendung mit dem Host sprechen, wie sie andernfalls mit jedem anderen Anschlußstellenstrom gesprochen hätte, und in diesem Fall unter Verwendung des telnet-Datenstroms, Schritt 414.
Wenn man von der Annahme ausgeht, daß die Leitweginitialisie rung durch einen Dämon oder eine Bibliotheksfunktion auf Host_A (und nicht Kernel-Code) erfolgt, dann hat der Anschlußstellencode von Host_A nicht viel mit dem Anschlußstellenleitweg zu tun. Grundsätzlich gilt: Wenn ein Anschlußstellen-Routing außerhalb des Betriebssystem-Kernels auf Host_A stattfindet, dann sind am Anschlußstellencode von Host_A keine Änderungen erforderlich.
Der folgende Programmiersprachcode und die folgende Beschreibung unter Bezugnahme auf Figur 5 legen dar, was auf host_B passiert:
*/on host_B/*
sockroute daemon receive connection from host_A
(asking for connection to host_C)
sockroute daemon consults route tyble -or route list provided with connection request.
sockroute daemon decides to connectto to host_C via SNA socket
(since it is last hop, it doesn't need to connect to a sockroute daemon on host_C)
when connection completes, host B sockroute daemon
1. sends response back to socket routing on host_A
2. cross connects the TCP and SNA sockets on host_B
when routing on host_A receives response, it pulls out of the way, leaving telnet connected all the way to host_C
Im wesentlichen beschreibt der obige Code das Szenario, in dem ein Dienst auf eine Verbindung wartet. Unter Bezugnahme auf Figur 5 empfängt der Sockroute-Dämon, der auf Host B läuft, Verbindungen von anderen Prozessen, die seine Dienste anfordern, Schritt 501. Der Sockroute-Dämon ist analog einem Telefondienst, der aufgefordert wird, von einem Anrufer eine Verbindung zu einer anderen Person herzustellen. Der Anforderungsprozeß, Anrufer, liefert einen Sockroute-Dämon, Telefondienst, mit der erforderlichen Verbindungsinformation, um die Verbindung herzustellen, Schritt 503. Sobald der Sockroute- Dämon die Verbindung herstellt, verläßt der Sockroute-Dämon die Verbindung. Wenn diese Verbindung zum endgültigen Ziel führt, Schritt 505, müssen keine weiteren Sockroute-Dämonen auf einem nächsten Host mehr angerufen werden, und der Sockroute-Dämon stellt eine Verbindung zum endgültigen Host- Ziel her, und zwar über eine SNA-Anschlußstelle, Schritt 507. Es ist allerdings möglich, mehrere Sockroute-Dämonen, Telefondienste, zur Verfügung zu haben, die benötigt werden, um eine Verbindung von einem ersten Host zu einem endgültigen Host- Ziel herzustellen. Wenn diese Verbindung nicht zum endgültigen Hostziel führt, dann muß ein weiterer Sockroute-Dämon auf einem nächsten Host aufgerufen, Schritt 506, und die obigen Schritte wiederholt werden.
Der Sockroute-Dämon auf Host_B sendet dann eine Antwort zurück zum Anschlußstellenleitdienst am ursprünglichen Host, Host_A, Schritt 509. Host_B stellt eine übergreifende Verbindung von TCP- und SNA-Anschlußstellen auf Host_B her, Schritt 511. Wenn der Leitdienst auf Host_A die Antwort empfängt, bewegt sich Host_B aus dem Weg. Dadurch bleibt eine telnet-Verbindung zwischen Host_A und Host C übrig, Schritt 513.
Es wird darauf hingewiesen, daß aufgrund der Tatsache, daß Host_C das Ende der Zeile ist, seine Anschlußstellenebene bei Datenübertragungszwecken nicht ins Spiel kommt.
Es gibt eine Funktion, die getpeername ( ) genannt wird, und die Bestandteil der Programmierschnittstelle der Anschlußstelle ist. Eine Anschlußstelle kann auch danach abgefragt werden, welcher Dienst an sie angeschlossen ist. Wenn beispielsweise Host_C seine Anschlußstelle auffordert, zu bestimmen, an welchen Dienst sie am anderen Ende angeschlossen war, wäre die Antwort der dazwischenliegende Host, Host_B, anstatt des tatsächlichen Dienstes am anderen Ende der Verbindung, der in diesem Beispiel Host_A ist. Daher würde die Funktion getpeername eine Eingabe vom Anschlußstellenleitwegcode an beiden Enden der Verbindung sowie einige Kernel-Änderungen benötigen, damit sie auf transparente Weise arbeiten kann. Im Sinne einer Transparenz würde die Funktion getpeername mit Host_A antworten, dem tatsächlichen Ende der vollständigen Verbindung, wenn die Anschlußstelle in Host_C nach der Partei am anderen Ende der Verbindung abgefragt würde.
Die näheren Einzelheiten der Adreßabbildung und der Anschlußstellenleitwegeinrichtungen innerhalb der Anschlußstellenebene 32, die die übergreifenden Bereichsverbindungen beeinflußt, werden nachfolgend beschrieben.
Gateway-Operationen von Protokollen auf der Grundlage von Anschlußstellen werden erzielt, indem man am oberen Ende zwei Anschlußstellen in einer Looping-Operation verbindet. Ein solcher Mechanismus würde einem Rooter ermöglichen, einen Pfad zu erstellen, der Bereichsgrenzen überschreiten würde. Ein Router in diesem Zusammenhang wäre der Programmcode, der entscheiden würde, wie man von einem Datenverarbeitungssystem zum anderen gelangen würde, wie dies beispielsweise in der internet-Ebene von TCP/IP der Fall ist. SNA besitzt ebenfalls einen ähnlichen Code. Der erforderliche Mechanismus, um am oberen Ende zwei Anschlußstellen in einer Looping-Operation miteinander zu verbinden, würde keine Dateideskriptoren oder Prozeßschaltzeiten am Verbindungsknoten erfordern, sobald die Verbindung hergestellt ist.
Die folgende Ausführung beschreibt die Änderungen an der Anschlußstellenebenenschnittstelle eines Betriebssystems, beispielsweise des Betriebssystems AIX, das die Berkeley- Anschlußstellen verwendet. Diese Änderungen können durchgeführt werden, um Anschlußstellenleitwege bevorzugter Ausführungsbeispiele der vorliegenden Erfindung zu implementieren. Diese Änderungen sind folgende:
* modify "connect" to catch cross domain connects
* add "connectto" to implement implicit routing from application level.
* as an option, create library functions for routing
* modify socket buffer handling, etc. to allow cross connections without process intervention
* as an option, add function so getpeername works transparently
* define socket routing protocol and messages (in kernel or as a daemon)
* if needed, modify nameserver for domain gateways and routing info.
Wird die Funktion connectto nicht verwendet, um das Routing in einer Bibliothek vor dem Benutzer verborgen zu halten, ist es auch möglich, Bibliotheksfunktionen zu erstellen, um das Routing durchzuführen. Der Benutzer benötigt dabei jedoch eine Einrichtung, um herauszufinden, welche Maschine einen Anschlußstellenleitwegdämon besitzt, um ein dazwischenliegendes Element zu bedienen. Diese Funktionen würden einem Benutzerprogramm gestatten, mit nur geringem Aufwand den Anschlußstellenleitweg aufzurufen. Eine Möglichkeit zur Definition einer Funktion wäre folgende:
* "get_route" - user programme asks for route (useable by connect ( ))
* "get_type_of_socket_I_should_open_to_get to host" - done against the return from "get_route" -or does implicit "get_route".
* connectto" - (1) looks up route, (2) creates a socket in proper domain, (3) established connection.
i.e., instead of
hp = gethostbyname (host);
(fill in sockaddr from hp ...)
so = socket (AF_XX, SOCK_STREAM,0);
connect (so, sockaddr, sockaddrlen);
a program does
so = connectto (host, SOCK_STREAM, 0);
Darüber hinaus gestattet die Änderung der Verarbeitung von Anschlußstellenpuffern übergreifende Verbindungen, ohne in den Prozeß eingreifen zu müssen. Bisher war eine Anschlußstelle so eingerichtet, daß, wenn die Daten ankommen, sie in einer Warteschlange gespeichert bleiben, solange sie in einem Prozeß darauf warten, gelesen zu werden. Am Gateway, der Anschlußstellenleitwegmaschine, müssen die Daten, wenn sie von einem Ende der Verbindung kommen, automatisch von der anderen Seite zum anderen Ende der Verbidnung geschickt werden, und umgekehrt.
Eine aktuelle Implementierung des Anschlußstellenpuffers würde erfordern, daß an allen Anschlußstellen ein Prozeß durchgeführt wird, die übergreifend miteinander verbunden sind. Ein wirksameres Mittel bestünde darin, diese übergreifende Verbindung an einer Anschlußstellenpufferebene hinzuzufügen, so daß keinerlei Prozeßplanung erforderlich ist, um die Daten loszusenden. In beiden Fällen werden den Anschlußstellendatenstrukturen Flags hinzugefügt.
Wie bereits angeführt wurde, wird der Funktion "getpeername" eine zusätzliche Funktion hinzugefügt, um dem dazwischenliegenden Host zu ermöglichen, in der Verbindung zwischen dem ursprünglichen Host-Ziel und dern endgültigen Host-Ziel transparent zu erscheinen. Bislang wurde die Anschlußstellensuchadresse von einem protokollabhängigen Mittel verarbeitet. Eine Änderung ist erforderlich, damit die Funktion getpeername ( ) korrekt arbeitet. Zur Änderung gehört es, daß die Suchadresse von den Leitwegdämonen in beide Richtungen verbreitet wird. Dann würde der Leitwegcode an jedem Ende der Verbindung eine Operation "set peer address" durchführen, die die Suchadreßfunktion des Protokolls übergehen würde.
Die Anschlußstellenleitwegeinrichtung der vorliegenden Erfindung benötigt außerdem ein Anschlußstellenleitwegprotokoll und Meldungen. Es ist wünschenswert, daß der Anschlußstellenleitwegcode das Routing auf flexible Weise verarbeiten kann. Um dies zu erreichen, besitzt ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung einen Anschlußstellenleitwegdämon auf jeder Maschine, die ein Gateway zwischen Bereichen ist. Der Dämon würde auf bekannten Anschlußstellen auf Leitweganforderungen warten. Bei Eingang einer Anforderung (über eine verbindende Anschlußstelle) würde der Leitwegdämon die Anforderung untersuchen und die gewünschte Funktion durchführen.
Diese Anforderungen (und ihre Antworten) sehen folgendermaßen aus:

Meldungen für Anschlußstellenleitwegprotokoll

- und die Informationen, die zu jeder Meldung gehören
Leitweganforderung - wird gesendet, um einen einzurichtenden Leitweg anzufordern
- ursprüngliche Adresse
- Schrittzieladresse
- Flag für dazwischenliegenden oder endgültigen Schritt
Leitweganforderungsantwort - wurde empfangen, um Abschluß und Erfolg/Mißerfolg der Leitweganforderung anzugeben.
- Status für Erfolg oder Mißerfolg
Verbindungsanforderung - wurde gesendet, um einen normalen Datenpfad herzustellen
- < none>
Verbindungsantwort - wurde empfangen, um Abschluß und Erfolg/Mißerfolg der Verbindungsanforderung anzugeben.
- Status für Erfolg oder Mißerfolg
Der Anschlußstellenleitwegdienstcode wird verwendet, um an den dazwischenliegenden Knoten, das heißt, am Gateway-Knoten ein Routing durchzuführen. Wenn an der Gateway-Maschine eine Anforderung nach einem Dienst, wie dies auch bei jeder anderen Anschlußstellenverbindung der Fall ist, eintrifft, würde die Anforderung nach einem Dienst an einer bestimmten Anschlußstelle ankommen, die die Anschlußstelle des Anschlußstellenleitwegdämons wäre. Wenn diese bestimmte Anschlußstelle geöffnet wäre, könnte sich der Prozeß entweder im Kernel befinden oder auf Benutzerebene laufen.
Daher kann der Anschlußstellenleitwegdienstcode als Dämon oder im Kernel erstellt werden. Vorzugsweise existiert der Anschlußstellenleitwegdienstcode zum größten Teil oder vollständig als Dämon. Einige kleinere Teile, wie beispielsweise ioctls (engl.: input output controls) zur Verknüpfung von Anschlußstellen, können als Bestandteil des Kernel existieren. Aber diese kleineren Teile unterstützen den Dämon und sind nicht wirklich Bestandteil des Anschlußstellenleitwegdienstcodes. Als Alternative ist es ebenfalls möglich, den Leitwegimplementierungsteil (im Gegensatz zum Dienstwegsuchteil) in den Kernel zu setzen, wodurch Prozeßkontextschaltdauer eingespart werden könnte.
Eine weitere Modifikation kann durchgeführt werden, um den Anschlußstellenleitweg der vorliegenden Erfindung zu implementieren. Der nameserver kann für Bereichs-Gateways und Leitweginformationen modifiziert werden. Der (Name) Bereichsnameserver braucht einen Datentyp für übergreifende Anschlußstellenbereichs-Gateways. Es wäre auch wünschenswert, Gateways zu finden, wenn man nach einer Host-Adresse sucht. Es wäre ebenfalls wünschenswert, wenn durch ein Flag angezeigt würde, daß ein Host ein übergreifendes Anschlußstellenbereichs- Gateway benötigt, um dorthin zu gelangen.
Zumindest in den bevorzugten Ausführungsbeispielen ist die vorliegende Erfindung zu folgenden Operationen in der Lage: automatisch auf Leitwegen Verbindungen zwischen Datenverarbeitungssystemen, die unterschiedliche Protokolle verwenden, herzustellen, und zwar unabhängig davon, ob die genannten Anwendungen auf den genannten Datenverarbeitungssystemen laufen; auf der Anschlußstellenebene Leitwege zwischen zwei Netzwerken herzustellen, wenn ein Versuch einer übergreifenden Bereichsverbindung erkannt wird; durch Schaffung der Möglichkeit, daß Anwendungen auf der Grundlage von Anschlußstellen sich mühelos auf verschiedene Netzwerke verteilen können, die übergreifende Verbindung zwischen zwei Datenverarbeitungssystemen herzustellen; zwischen Datenverarbeitungssystemen zu kommunizieren, in denen eines der Datenverarbeitungssysteme TCP/IP und das andere Datenverarbeitungssystem SNA verwendet; über ein drittes Datenverarbeitungssystem, das als TCP-zu-SNA- Gateway verwendet wird, zwischen zwei Datenverarbeitungssystemen zu kommunizieren; und durch eine Verbindung zwischen zwei Datenverarbeitungssystemen zu kommunizieren, von denen jedes TCP auf jedem seiner lokalen Internets verwendet, indem die Netzwerkverbindung mit einer langen SNA-Verbindung überbrückt wird.
Zwar wurde die vorliegende Erfindung insbesondere in bezug auf ein bevorzugtes Ausführungsbeispiel unter Einbeziehung von Anschlußstellen dargestellt und beschrieben, doch könnte die zugrundeliegende Idee übergreifender Bereichsverbindungen auch mit anderen Betriebssystemen mit anderen Kommunikationsendpunkten als Anschlußstellen erreicht werden.

Claims

1. Ein System zur Kommunikation zwischen einem ersten Datenverarbeitungssystem (11) in einem ersten Netzwerkbereich und einem zweiten Datenverarbeitungssystem (41) in einem zweiten Netzwerkbereich, wobei der genannte erste Netzwerkbereich eine Netzwerkprotokollarchitektur besitzt, die sich vorn genannten zweiten Netzwerkbereich unterscheidet, wobei das genannte System mindestens ein Kommunikationsendpunktobjekt in einer Ebene (12) des genannten ersten Datenverarbeitungssystems (11) im genannten ersten Netzwerkbereich und mindestens ein Kommunikationsendpunktobjekt in einer Ebene (42) des genannten zweiten Datenverarbeitungssystems (41) im genannten zweiten Netzwerkbereich umfaßt, wobei das System charakterisiert ist durch:

ein Verbindungsmittel (70), das unabhängig von einem Anwendungsprogramm (10, 40) ist, das auf einem der beiden genannten Datenverarbeitungssysteme läuft, um automatisch auf der genannten Ebene (12) des genannten ersten Datenverarbeitungssystems (11) und auf der genannten Ebene (42) des genannten zweiten Datenverarbeitungssystems (41) eine Verbindung zwischen dem genannten ersten Datenverarbeitungssystem (11) und dem genannten zweiten Datenverarbeitungssystem (41) eine Verbindung herzustellen, wobei das Verbindungsmittel ein Routing-Mittel (702, 703) zur Bestimmung eines Leitwegs für die Verbindung zwischen dem genannten ersten und zweiten Netzwerkbereich

sowie ein Mittel (706, 707, 708) zur Kommunikation auf der genannten Verbindung zwischen dem genannten ersten Datenverarbeitungssystem (11) und dem genannten zweiten Datenverarbeitungssystem (41) umfaßt.

2. Ein System gemäß Anspruch 1, bei dem es sich beim ersten Netzwerkbereich um ein Übertragungssteuerprotokoll und beim zweiten Netzwerkbereich um eine Systemnetzwerkarchitektur handelt.

3. Ein System gemäß Anspruch 1 oder 2, des weiteren bestehend aus mindestens einem Kommunikationsendpunktobjekt in der genannten Ebene (32)- eines dazwischenliegenden Datenverarbeitungssysterns (31), wobei jedes dieser Kommunikationsendpunktobjekte zur Kommunikation unter Verwendung entweder der Netzwerkprotokollarchitektur des ersten Netzwerkbereichs oder der Netzwerkprotokollarchitektur des zweiten Netzwerkbereichs ausgelegt ist, wobei sich das genannte Verbindungsmittel (70) im genannten dazwischenliegenden Datenverarbeitungssystem (31) befindet und die genannte Verbindung durch das genannte dazwischenliegende Datenverarbeitungssystem (31) läuft.

4. Ein System gemäß Anspruch 3, bei dem das genannte Verbindungsmittel (70) eine Verbindungslogik (706, 707, 708) umfaßt, die zwischen Kommunikationsendpunktobjekten im genannten dazwischenliegenden Datenverarbeitungssystem (31) liegt, um Daten von einem Kommunikationsendpunktobjekt, das für die Kommunikation unter Verwendung der Netzwerkprotokollarchitektur des ersten Netzwerkbereichs ausgelegt ist, zu einem Kommunikationsendpunktobjekt zu leiten, das für die Kommunikation unter Verwendung der Netzwerkprotokollarchitektur des zweiten Netzwerkbereichs ausgelegt ist.

5. Ein System gemäß Anspruch 3 oder 4, bei dem sich das genannte Kommunikationsmittel im genannten dazwischenliegenden Datenverarbeitungssystem liegt und dieses Kommunikationsmittel sofort alle Daten, die es von einem Ende der genannten Verbindung empfängt, an das genannte andere Ende der genannten Verbindung sendet.

6. Ein System gemäß allen vorherigen Ansprüchen, wobei die genannten Kommunikationsendpunktobjekte Anschlußstellen sind und die genannten Ebenen (12, 32, 42) Anschlußstellenebenen sind.

7. Ein Verfahren zum Betrieb eines Systems zur Kommunikation zwischen einem ersten Datenverarbeitungssystem (11) in einem ersten Netzwerkbereich und einem zweiten Datenverarbeitungssystem (41) in einem zweiten Netzwerkbereich, wobei der genannte erste Netzwerkbereich eine Netzwerkprotokollarchitektur besitzt, die sich vom genannten zweiten Netzwerkbereich unterscheidet, wobei das genannte Verfahren die Schritte zur Erstellung mindestens eines Kommunikationsendpunktobjekts in einer Ebene (12) des genannten ersten Datenverarbeitungssystems (11) im genannten ersten Netzwerkbereich und und der Erstellung mindestens eines Kommunikationsendpunktobjekts in einer Ebene (42) des genannten zweiten Datenverarbeitungssystems (41) im genannten zweiten Netzwerkbereich umfaßt, wobei das Verfahren weiterhin durch folgende Schritte charakterisiert ist:

Verwendung eines Verbindungsmittels (70), das unabhängig von einem Anwendungsprogramm (10, 40) ist, das auf einem der beiden genannten Datenverarbeitungssysteme läuft, um automatisch auf der genannten Ebene (12) des genannten ersten Datenverarbeitungssystems (11) und auf der genannten Ebene (42) des genannten zweiten Datenverarbeitungssystems (41) eine Verbindung zwischen dem genannten ersten Datenverarbeitungssystem (11) und dem genannten zweiten Datenverarbeitungssystem (41) eine Verbindung herzustellen, wobei das Verbindungsmittel ein Routing- Mittel (702, 703) zur Bestimmung eines Leitwegs für die Verbindung zwischen dem genannten ersten und zweiten Netzwerkbereich umfaßt;

und auf der genannten Verbindung zwischen dem genannten ersten Datenverarbeitungssystem und dem genannten zweiten Datenverarbeitungssystem kommuniziert.

8. Ein Verfahren gemäß Anspruch 7, bei dem es sich bei den genannten Kommunikationsendpunktobjekten um Anschlußstellen und bei den genannten Ebenen (12, 32, 42) um Anschlußstellenebenen handelt.