DE69026400T2 - System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von Datenverarbeitungssystemen - Google Patents
System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von DatenverarbeitungssystemenInfo
- Publication number
- DE69026400T2 DE69026400T2 DE69026400T DE69026400T DE69026400T2 DE 69026400 T2 DE69026400 T2 DE 69026400T2 DE 69026400 T DE69026400 T DE 69026400T DE 69026400 T DE69026400 T DE 69026400T DE 69026400 T2 DE69026400 T2 DE 69026400T2
- Authority
- DE
- Germany
- Prior art keywords
- data processing
- processing system
- connection
- network
- port
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000012545 processing Methods 0.000 title claims description 93
- 238000000034 method Methods 0.000 title claims description 24
- 238000004891 communication Methods 0.000 claims description 35
- 230000005540 biological transmission Effects 0.000 claims description 4
- 230000006870 function Effects 0.000 description 50
- 230000008569 process Effects 0.000 description 17
- 230000004044 response Effects 0.000 description 8
- 239000003795 chemical substances by application Substances 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 239000000872 buffer Substances 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 241000408659 Darpa Species 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000007123 defense Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241000233805 Phoenix Species 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
- G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
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:
- - 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 (8)
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.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/304,696 US5142622A (en) | 1989-01-31 | 1989-01-31 | System for interconnecting applications across different networks of data processing systems by mapping protocols across different network domains |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69026400D1 DE69026400D1 (de) | 1996-05-15 |
DE69026400T2 true DE69026400T2 (de) | 1996-10-10 |
Family
ID=23177594
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69026400T Expired - Lifetime DE69026400T2 (de) | 1989-01-31 | 1990-01-24 | System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von Datenverarbeitungssystemen |
Country Status (4)
Country | Link |
---|---|
US (1) | US5142622A (de) |
EP (1) | EP0381365B1 (de) |
JP (1) | JPH0626360B2 (de) |
DE (1) | DE69026400T2 (de) |
Families Citing this family (153)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0743683B2 (ja) * | 1989-02-13 | 1995-05-15 | 日本電気株式会社 | プロトコルマシン |
ATE121208T1 (de) * | 1990-01-30 | 1995-04-15 | Johnson Service Co | Vernetztes betriebsmittelverwaltungssystem. |
US5278955A (en) * | 1990-06-18 | 1994-01-11 | International Business Machines Corporation | Open systems mail handling capability in a multi-user environment |
US5363121A (en) * | 1990-06-29 | 1994-11-08 | International Business Machines Corporation | Multiple protocol communication interface for distributed transaction processing |
AU639802B2 (en) * | 1990-08-14 | 1993-08-05 | Oracle International Corporation | Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment |
AU628753B2 (en) * | 1990-08-14 | 1992-09-17 | Digital Equipment Corporation | Method and apparatus for implementing server functions in a distributed heterogeneous environment |
AU631749B2 (en) * | 1990-09-14 | 1992-12-03 | Digital Equipment Corporation | System and method for communication between windowing environments |
TW313282U (en) * | 1991-03-07 | 1997-08-11 | Digital Equipment Corp | Apparatus for automatically interfacing call conventions between two dissimilar program units |
DE69216020T2 (de) * | 1991-03-07 | 1997-07-10 | Digital Equipment Corp | Verbessertes fehlersuchsystem und -verfahren, besonders für die fehlersuche in einer multi-architekturumgebung |
US5680584A (en) * | 1991-03-07 | 1997-10-21 | Digital Equipment Corporation | Simulator system for code execution and debugging within a multi-architecture environment |
US5652869A (en) * | 1991-03-07 | 1997-07-29 | Digital Equipment Corporation | System for executing and debugging multiple codes in a multi-architecture environment using jacketing means for jacketing the cross-domain calls |
US6115393A (en) * | 1991-04-12 | 2000-09-05 | Concord Communications, Inc. | Network monitoring |
JPH0797782B2 (ja) * | 1991-09-18 | 1995-10-18 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 異種トランザクションの調整方法 |
EP0537903A2 (de) * | 1991-10-02 | 1993-04-21 | International Business Machines Corporation | Verteiltes Kontrollsystem |
US5396417A (en) * | 1991-11-01 | 1995-03-07 | Capitol Cities/Abc, Inc. | Product distribution equipment and method |
EP0556148B1 (de) * | 1992-01-10 | 1998-07-22 | Digital Equipment Corporation | Verfahren zur Verbindung einer Leitungskarte mit einer Adressenerkennungseinheit |
EP0648354B1 (de) * | 1992-07-01 | 2000-10-18 | Telefonaktiebolaget Lm Ericsson | Verfahren und system für implementierung-unabhängige schnittstellenspezifikation |
US5490252A (en) * | 1992-09-30 | 1996-02-06 | Bay Networks Group, Inc. | System having central processor for transmitting generic packets to another processor to be altered and transmitting altered packets back to central processor for routing |
US5432711A (en) * | 1992-10-16 | 1995-07-11 | Elcon Instruments, Inc. | Interface for use with a process instrumentation system |
US5784622A (en) * | 1992-11-18 | 1998-07-21 | Canon Kabushiki Kaisha | Method and apparatus for multiprotocol operation of a networked peripheral |
US5696899A (en) * | 1992-11-18 | 1997-12-09 | Canon Kabushiki Kaisha | Method and apparatus for adaptively determining the format of data packets carried on a local area network |
US5619650A (en) * | 1992-12-31 | 1997-04-08 | International Business Machines Corporation | Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message |
US5537417A (en) * | 1993-01-29 | 1996-07-16 | International Business Machines Corporation | Kernel socket structure for concurrent multiple protocol access |
US5406643A (en) * | 1993-02-11 | 1995-04-11 | Motorola, Inc. | Method and apparatus for selecting between a plurality of communication paths |
WO1995001601A1 (en) * | 1993-07-02 | 1995-01-12 | Oakleigh Systems, Inc. | High-speed cpu interconnect bus architecture |
US5613090A (en) * | 1993-10-05 | 1997-03-18 | Compaq Computer Corporation | Computer system for disparate windowing environments which translates requests and replies between the disparate environments |
DE69432503T2 (de) * | 1993-10-08 | 2003-12-24 | Ibm | Informationsarchivierungssystem mit objektabhängiger Funktionalität |
US5742848A (en) * | 1993-11-16 | 1998-04-21 | Microsoft Corp. | System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions |
US5475601A (en) * | 1994-02-15 | 1995-12-12 | Emhart Glass Machinery Investments Inc. | Control for glassware forming system including bidirectional network gateway |
US5717855A (en) * | 1994-02-28 | 1998-02-10 | International Business Machines Corporation | Segmented communications adapter with packet transfer interface |
US5509123A (en) * | 1994-03-22 | 1996-04-16 | Cabletron Systems, Inc. | Distributed autonomous object architectures for network layer routing |
DE4414171A1 (de) * | 1994-04-22 | 1995-10-26 | Paul Bantzer | Verfahren und System zur Steuerung von Prozessen in einem Computer-Netzwerk |
US5485460A (en) * | 1994-08-19 | 1996-01-16 | Microsoft Corporation | System and method for running multiple incompatible network protocol stacks |
US5680615A (en) * | 1994-11-04 | 1997-10-21 | International Business Machines Corporation | Desktop management of host applications |
US5586261A (en) * | 1994-11-10 | 1996-12-17 | International Business Machines Corporation | Method and apparatus for interconnecting similar networks using a network of a diffrent type as a virtual link |
US5563878A (en) * | 1995-01-05 | 1996-10-08 | International Business Machines Corporation | Transaction message routing in digital communication networks |
US5640540A (en) * | 1995-02-13 | 1997-06-17 | International Business Machines Corporation | Method and apparatus for translating key codes between servers over a conference networking system |
US7058067B1 (en) | 1995-03-13 | 2006-06-06 | Cisco Technology, Inc. | Distributed interactive multimedia system architecture |
US5838683A (en) | 1995-03-13 | 1998-11-17 | Selsius Systems Inc. | Distributed interactive multimedia system architecture |
US5721876A (en) * | 1995-03-30 | 1998-02-24 | Bull Hn Information Systems Inc. | Sockets application program mechanism for proprietary based application programs running in an emulation environment |
US5619645A (en) * | 1995-04-07 | 1997-04-08 | Sun Microsystems, Inc. | System isolation and fast-fail |
US5664185A (en) * | 1995-05-22 | 1997-09-02 | Sterling Commerce, Inc. | Nameserver administration system and method |
US5978575A (en) * | 1995-07-07 | 1999-11-02 | Sun Microsystems, Inc. | Remote terminal emulator with improved time accounting |
US5638448A (en) * | 1995-10-24 | 1997-06-10 | Nguyen; Minhtam C. | Network with secure communications sessions |
US5689566A (en) * | 1995-10-24 | 1997-11-18 | Nguyen; Minhtam C. | Network with secure communications sessions |
US5740362A (en) * | 1995-11-06 | 1998-04-14 | International Business Machines Corporation | Management of network distributed agents in a distributed computing environment |
GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
US5777989A (en) * | 1995-12-19 | 1998-07-07 | International Business Machines Corporation | TCP/IP host name resolution for machines on several domains |
US7336649B1 (en) | 1995-12-20 | 2008-02-26 | Verizon Business Global Llc | Hybrid packet-switched and circuit-switched telephony system |
US5732213A (en) * | 1996-03-22 | 1998-03-24 | Ericsson Inc. | System and method of testing open systems interconnection (OSI) layers in telecommunication networks |
US5774695A (en) * | 1996-03-22 | 1998-06-30 | Ericsson Inc. | Protocol interface gateway and method of connecting an emulator to a network |
US6154445A (en) | 1996-04-18 | 2000-11-28 | Bell Atlantic Network Services, Inc. | Telephony communication via varied redundant networks |
US6069890A (en) | 1996-06-26 | 2000-05-30 | Bell Atlantic Network Services, Inc. | Internet telephone service |
GB2313456A (en) * | 1996-05-24 | 1997-11-26 | Ibm | Heterogeneous operations with differing transaction protocols |
JP3636399B2 (ja) * | 1996-05-29 | 2005-04-06 | 富士通株式会社 | プロトコル変換システム及びプロトコル変換方法 |
US6031978A (en) | 1996-06-28 | 2000-02-29 | International Business Machines Corporation | System, method and program for enabling a client to reconnect to a same server in a network of computer systems after the server has moved to a different network address |
US6470398B1 (en) * | 1996-08-21 | 2002-10-22 | Compaq Computer Corporation | Method and apparatus for supporting a select () system call and interprocess communication in a fault-tolerant, scalable distributed computer environment |
US5839088A (en) | 1996-08-22 | 1998-11-17 | Go2 Software, Inc. | Geographic location referencing system and method |
US6229809B1 (en) | 1996-10-11 | 2001-05-08 | Novell, Inc. | Method and system for combining computer network protocols |
US6802068B1 (en) * | 1996-10-16 | 2004-10-05 | International Business Machines Corporation | Addressless internetworking |
US6078582A (en) | 1996-12-18 | 2000-06-20 | Bell Atlantic Network Services, Inc. | Internet long distance telephone service |
US5889954A (en) * | 1996-12-20 | 1999-03-30 | Ericsson Inc. | Network manager providing advanced interconnection capability |
US5966451A (en) * | 1997-02-20 | 1999-10-12 | Kabushiki Kaisha Toshiba | Distributed network computing system, and data exchange apparatus and method and storage medium used in this system |
US6137869A (en) | 1997-09-16 | 2000-10-24 | Bell Atlantic Network Services, Inc. | Network session management |
US6247068B1 (en) * | 1997-03-07 | 2001-06-12 | Advanced Micro Devices Inc. | Winsock-data link library transcoder |
US6574216B1 (en) | 1997-03-11 | 2003-06-03 | Verizon Services Corp. | Packet data network voice call quality monitoring |
NZ337772A (en) | 1997-03-12 | 2001-09-28 | Nomadix Inc | Nomadic translator or router |
US6292479B1 (en) | 1997-03-19 | 2001-09-18 | Bell Atlantic Network Services, Inc. | Transport of caller identification information through diverse communication networks |
US6870827B1 (en) | 1997-03-19 | 2005-03-22 | Verizon Services Corp. | Voice call alternative routing through PSTN and internet networks |
WO1998055908A2 (en) * | 1997-06-04 | 1998-12-10 | Pangea Systems, Inc. | Method and apparatus for obtaining results from multiple computer applications |
US6122276A (en) * | 1997-06-30 | 2000-09-19 | Cisco Technology, Inc. | Communications gateway mapping internet address to logical-unit name |
US6324183B1 (en) | 1998-12-04 | 2001-11-27 | Tekelec | Systems and methods for communicating messages among signaling system 7 (SS7) signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPS) |
US7050456B1 (en) | 1998-12-04 | 2006-05-23 | Tekelec | Methods and systems for communicating signaling system 7 (SS7) user part messages among SS7 signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPs) |
US6944184B1 (en) * | 1998-12-04 | 2005-09-13 | Tekelec | Methods and systems for providing database node access control functionality in a communications network routing node |
US6049833A (en) * | 1997-08-29 | 2000-04-11 | Cisco Technology, Inc. | Mapping SNA session flow control to TCP flow control |
US6128662A (en) * | 1997-08-29 | 2000-10-03 | Cisco Technology, Inc. | Display-model mapping for TN3270 client |
US6006258A (en) * | 1997-09-12 | 1999-12-21 | Sun Microsystems, Inc. | Source address directed message delivery |
US6215776B1 (en) | 1997-10-08 | 2001-04-10 | Lockheed Martin Missiles & Space Company | Satellite communication system |
NL1007252C1 (nl) * | 1997-10-10 | 1999-04-13 | Ralph Rogier De La Bretoniere | Werkwijze en inrichting voor het beveiligen van datacommunicatie. |
EA002886B1 (ru) * | 1997-11-13 | 2002-10-31 | Хайперспейс Коммьюникейшнз, Инк. | Система пересылки файлов |
US6157950A (en) * | 1997-12-05 | 2000-12-05 | Encanto Networks, Inc. | Methods and apparatus for interfacing a computer or small network to a wide area network such as the internet |
US6131117A (en) * | 1997-12-29 | 2000-10-10 | Cisco Technology, Inc. | Technique for correlating logical names with IP addresses on internetworking platforms |
US5946465A (en) | 1998-03-30 | 1999-08-31 | International Business Machines Corporation | Method and system for recovering system resources used by an inactive Telnet client |
DE69927454T2 (de) | 1998-04-06 | 2006-03-23 | Panasonic Communications Co., Ltd. | Bildkommunikationsvorrichtung und verfahren |
US6987781B1 (en) | 1998-12-04 | 2006-01-17 | Tekelec | Methods and systems for routing signaling messages in a communications network using circuit identification code (CIC) information |
US7002988B1 (en) | 1998-12-04 | 2006-02-21 | Tekelec | Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface |
US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
FI108980B (fi) * | 1998-12-22 | 2002-04-30 | Ericsson Telefon Ab L M | Kuljetusmekanismi matkapuhelinosaa varten |
US6954526B1 (en) | 1999-04-05 | 2005-10-11 | Tekelec | Methods and systems for routing calling name service query messages in a communication network |
US6532241B1 (en) | 1999-05-20 | 2003-03-11 | Cisco Technology, Inc. | Method and apparatus for determining SNA sessions using various protocols for transport based on filter criteria |
US6571272B1 (en) | 1999-05-20 | 2003-05-27 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation with multiple DSW peer connections |
US6490618B1 (en) | 1999-05-20 | 2002-12-03 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation in a mixed APPN and DLSW network |
US6430595B1 (en) | 1999-05-20 | 2002-08-06 | Cisco Technology, Inc. | Method and apparatus for establishing a database used for correlating information gathered via SNMP |
US6934381B1 (en) | 1999-08-16 | 2005-08-23 | Avaya Technology Corp. | Contact routing system and method |
US6963827B1 (en) | 1999-09-29 | 2005-11-08 | United States Postal Service | System and method for performing discrete simulation of ergonomic movements |
WO2001031885A2 (en) | 1999-10-22 | 2001-05-03 | Nomadix, Inc. | Gateway device having an xml interface and associated method |
US6772413B2 (en) | 1999-12-21 | 2004-08-03 | Datapower Technology, Inc. | Method and apparatus of data exchange using runtime code generator and translator |
US7007080B2 (en) | 1999-12-23 | 2006-02-28 | Solution Inc Limited | System for reconfiguring and registering a new IP address for a computer to access a different network without user intervention |
EP1277355B1 (de) | 2000-04-21 | 2016-06-08 | Tekelec Global, Inc. | Verfahren und systeme zum bereitstellen einer dynamischen registrierung für leitweglenkungsschlüssel |
US7149816B1 (en) | 2000-05-16 | 2006-12-12 | Lucent Technologies Inc. | System and method for peer-level communication with a network interface card |
US7318091B2 (en) | 2000-06-01 | 2008-01-08 | Tekelec | Methods and systems for providing converged network management functionality in a gateway routing node to communicate operating status information associated with a signaling system 7 (SS7) node to a data network node |
US6731313B1 (en) | 2000-06-23 | 2004-05-04 | Igt | Gaming device having touch activated alternating or changing symbol |
US7699699B2 (en) | 2000-06-23 | 2010-04-20 | Igt | Gaming device having multiple selectable display interfaces based on player's wagers |
US7695363B2 (en) | 2000-06-23 | 2010-04-13 | Igt | Gaming device having multiple display interfaces |
US6967956B1 (en) | 2000-07-18 | 2005-11-22 | Tekelec | Methods and systems for providing message translation, accounting and routing service in a multi-protocol communications network environment |
US6912522B2 (en) * | 2000-09-11 | 2005-06-28 | Ablesoft, Inc. | System, method and computer program product for optimization and acceleration of data transport and processing |
US6990089B2 (en) * | 2000-12-12 | 2006-01-24 | Telelec | Methods and systems for routing messages in a radio access network |
US7673133B2 (en) * | 2000-12-20 | 2010-03-02 | Intellisync Corporation | Virtual private network between computing network and remote device |
US8266677B2 (en) * | 2000-12-20 | 2012-09-11 | Intellisync Corporation | UDP communication with a programmer interface over wireless networks |
US6965592B2 (en) * | 2001-01-24 | 2005-11-15 | Tekelec | Distributed signaling system 7 (SS7) message routing gateway |
US6950437B2 (en) * | 2001-04-24 | 2005-09-27 | Atitania Ltd. | System and method for transmission of information between locations on a computer network with the use of unique packets |
US6975595B2 (en) * | 2001-04-24 | 2005-12-13 | Atttania Ltd. | Method and apparatus for monitoring and logging the operation of a distributed processing system |
US20030061405A1 (en) * | 2001-08-15 | 2003-03-27 | Open Technologies Group, Inc. | System, method and computer program product for protocol-independent processing of information in an enterprise integration application |
US7257620B2 (en) * | 2001-09-24 | 2007-08-14 | Siemens Energy & Automation, Inc. | Method for providing engineering tool services |
US7389359B2 (en) * | 2001-10-19 | 2008-06-17 | Foundry Networks, Inc. | Method and system for intelligently forwarding multicast packets |
CN1742267B (zh) * | 2002-10-04 | 2012-11-28 | 思达伦特网络有限责任公司 | 用于管理联网中的资源的方法 |
US7318097B2 (en) * | 2003-06-17 | 2008-01-08 | International Business Machines Corporation | Security checking program for communication between networks |
US20050097537A1 (en) * | 2003-10-30 | 2005-05-05 | Laura Joseph G. | System and method for distributed processing in COBOL |
US7254739B2 (en) * | 2003-11-19 | 2007-08-07 | International Business Machines Corporation | Error recovery in a client/server application using two independent sockets for communication |
US20050149624A1 (en) * | 2003-11-21 | 2005-07-07 | Daniel Jakubiec | Modular communication server |
US7804789B2 (en) | 2004-03-18 | 2010-09-28 | Tekelec | Methods, systems, and computer program products for organizing, managing, and selectively distributing routing information in a signaling message routing node |
US20050281249A1 (en) * | 2004-06-18 | 2005-12-22 | Nokia Corporation | Multi-instancing of routing/forwarding tables and socket API |
US7532647B2 (en) | 2004-07-14 | 2009-05-12 | Tekelec | Methods and systems for auto-correlating message transfer part (MTP) priority and internet protocol (IP) type of service in converged networks |
US8021230B2 (en) | 2004-08-19 | 2011-09-20 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
US7963847B2 (en) | 2004-08-19 | 2011-06-21 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
US8251791B2 (en) | 2004-08-19 | 2012-08-28 | Igt | Gaming system having multiple gaming machines which provide bonus awards |
WO2006056256A2 (de) * | 2004-11-19 | 2006-06-01 | Richard Bergner Verbindungstechnik Gmbh & Co Kg | Hydraulikaggregat sowie verfahren zur bereitstellung einer unter druck stehenden hydraulikflüssigkeit |
US8137188B2 (en) | 2005-09-09 | 2012-03-20 | Igt | Server based gaming system having multiple progressive awards |
US7568973B2 (en) | 2005-09-09 | 2009-08-04 | Igt | Server based gaming system having multiple progressive awards |
US7841939B2 (en) | 2005-09-09 | 2010-11-30 | Igt | Server based gaming system having multiple progressive awards |
US8128491B2 (en) | 2005-09-09 | 2012-03-06 | Igt | Server based gaming system having multiple progressive awards |
US8512130B2 (en) | 2006-07-27 | 2013-08-20 | Igt | Gaming system with linked gaming machines that are configurable to have a same probability of winning a designated award |
US20080056290A1 (en) * | 2006-09-06 | 2008-03-06 | Nikhil Hegde | Controlling the data-packet transmit interval of network dependent applications (nda)using device driver feedback |
US7862430B2 (en) | 2006-09-27 | 2011-01-04 | Igt | Server based gaming system having system triggered loyalty award sequences |
US8616959B2 (en) | 2006-09-27 | 2013-12-31 | Igt | Server based gaming system having system triggered loyalty award sequences |
US7674180B2 (en) | 2006-09-27 | 2010-03-09 | Igt | Server based gaming system having system triggered loyalty award sequences |
US7985133B2 (en) | 2007-07-30 | 2011-07-26 | Igt | Gaming system and method for providing an additional gaming currency |
US9043451B2 (en) | 2007-07-31 | 2015-05-26 | Tekelec, Inc. | Methods, systems, and computer readable media for managing the flow of signaling traffic entering a signaling system 7 (SS7) based network |
US8900053B2 (en) | 2007-08-10 | 2014-12-02 | Igt | Gaming system and method for providing different bonus awards based on different types of triggered events |
US9142097B2 (en) | 2007-10-26 | 2015-09-22 | Igt | Gaming system and method for providing play of local first game and remote second game |
US8825883B2 (en) * | 2008-02-29 | 2014-09-02 | Microsoft Corporation | Connectivity platform |
US8364847B2 (en) | 2008-02-29 | 2013-01-29 | Microsoft Corporation | Address management in a connectivity platform |
CN101662460B (zh) | 2008-08-25 | 2015-07-15 | 阿里巴巴集团控股有限公司 | 一种跨域通讯的方法、***和装置 |
US8549093B2 (en) * | 2008-09-23 | 2013-10-01 | Strategic Technology Partners, LLC | Updating a user session in a mach-derived system environment |
WO2010083509A2 (en) | 2009-01-16 | 2010-07-22 | Tekelec | Methods, systems, and computer readable media for centralized routing and call instance code management for bearer independent call control (bicc) signaling messages |
US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
US9039516B2 (en) | 2009-07-30 | 2015-05-26 | Igt | Concurrent play on multiple gaming machines |
US8625427B1 (en) | 2009-09-03 | 2014-01-07 | Brocade Communications Systems, Inc. | Multi-path switching with edge-to-edge flow control |
EP2534790B1 (de) | 2010-02-12 | 2016-04-27 | Tekelec, Inc. | Verfahren, systeme und computerlesbare medien für eine durchmesserlastenteilung auf basis einer quelleninhaltskapazität |
US9875618B2 (en) | 2014-07-24 | 2018-01-23 | Igt | Gaming system and method employing multi-directional interaction between multiple concurrently played games |
US9972171B2 (en) | 2015-09-24 | 2018-05-15 | Igt | Gaming system and method for providing a triggering event based on a collection of units from different games |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2023314B (en) * | 1978-06-15 | 1982-10-06 | Ibm | Digital data processing systems |
US4322792A (en) * | 1979-12-14 | 1982-03-30 | Burroughs Corporation | Common front-end control for a peripheral controller connected to a computer |
US4415986A (en) * | 1980-05-07 | 1983-11-15 | Burroughs Corporation | Data flow control system |
US4500960A (en) * | 1982-06-28 | 1985-02-19 | At&T Bell Laboratories | Geographically distributed multiprocessor time-shared communication processing system |
US4530051A (en) * | 1982-09-10 | 1985-07-16 | At&T Bell Laboratories | Program process execution in a distributed multiprocessor system |
US4631666A (en) * | 1982-10-25 | 1986-12-23 | Burroughs Corporation | Data transfer network for variable protocol management |
SE448919B (sv) * | 1983-03-04 | 1987-03-23 | Ibm Svenska Ab | Metod for att overfora informationsenheter i ett datornetsystem, samt datornetsystem for genomforande av metoden |
US4575793A (en) * | 1983-08-19 | 1986-03-11 | Cxi, Inc. | Personal-computer to 3270 system interfacing apparatus |
US4677588A (en) * | 1983-11-14 | 1987-06-30 | International Business Machines Corp. | Network interconnection without integration |
US4604686A (en) * | 1984-01-27 | 1986-08-05 | Martin Marietta Corporation | Associative data access method (ADAM) and its means of implementation |
EP0200721B1 (de) * | 1984-10-23 | 1988-08-24 | Televerket | Anordnung zur datenübertragung zwischen zu verschiedenen netzwerkarchitekturen gehörenden geräten |
US4706081A (en) * | 1984-12-14 | 1987-11-10 | Vitalink Communications Corporation | Method and apparatus for bridging local area networks |
US4612416A (en) * | 1985-01-22 | 1986-09-16 | At&T Information Systems Inc. | Integrated message service system |
US4882674A (en) * | 1985-03-05 | 1989-11-21 | Wang Laboratories, Inc. | Apparatus and method for control of one computer system by another computer system |
US4825354A (en) * | 1985-11-12 | 1989-04-25 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method of file access in a distributed processing computer network |
JPS62128638A (ja) * | 1985-11-20 | 1987-06-10 | Nissin Electric Co Ltd | 階層化デ−タ伝送方式 |
US4679189A (en) * | 1985-11-27 | 1987-07-07 | American Telephone And Telegraph Company | Alternate routing arrangement |
US4703475A (en) * | 1985-12-04 | 1987-10-27 | American Telephone And Telegraph Company At&T Bell Laboratories | Data communication method and apparatus using multiple physical data links |
US4736369A (en) * | 1986-06-13 | 1988-04-05 | International Business Machines Corp. | Adaptive session-level pacing |
US4831518A (en) * | 1986-08-26 | 1989-05-16 | Bull Hn Information Systems Inc. | Multiprocessor interrupt rerouting mechanism |
US4768150A (en) * | 1986-09-17 | 1988-08-30 | International Business Machines Corporation | Application program interface to networking functions |
US4901231A (en) * | 1986-12-22 | 1990-02-13 | American Telephone And Telegraph Company | Extended process for a multiprocessor system |
US4811216A (en) * | 1986-12-22 | 1989-03-07 | American Telephone And Telegraph Company | Multiprocessor memory management method |
US4849877A (en) * | 1986-12-22 | 1989-07-18 | American Telephone And Telegraph Company | Virtual execution of programs on a multiprocessor system |
US4790003A (en) * | 1987-04-27 | 1988-12-06 | American Telephone And Telegraph Company, At&T Information Systems | Message service system network |
US4855906A (en) * | 1987-10-23 | 1989-08-08 | Allen-Bradley Company, Inc. | System for handling unsolicited messages from lower-tier controllers |
US4893307A (en) * | 1988-02-29 | 1990-01-09 | International Business Machines Corporation | Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network |
JPH088571B2 (ja) * | 1988-06-28 | 1996-01-29 | 富士通株式会社 | ネットワークの制御方法 |
-
1989
- 1989-01-31 US US07/304,696 patent/US5142622A/en not_active Expired - Lifetime
-
1990
- 1990-01-24 DE DE69026400T patent/DE69026400T2/de not_active Expired - Lifetime
- 1990-01-24 EP EP90300739A patent/EP0381365B1/de not_active Expired - Lifetime
- 1990-01-31 JP JP2019391A patent/JPH0626360B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JPH02235462A (ja) | 1990-09-18 |
JPH0626360B2 (ja) | 1994-04-06 |
EP0381365B1 (de) | 1996-04-10 |
EP0381365A3 (de) | 1991-04-17 |
DE69026400D1 (de) | 1996-05-15 |
US5142622A (en) | 1992-08-25 |
EP0381365A2 (de) | 1990-08-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69026400T2 (de) | System und Verfahren zur Verbindung von Anwendungen über verschiedene Netzwerke von Datenverarbeitungssystemen | |
DE69814900T2 (de) | Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software | |
DE69636369T2 (de) | Virtuelles lokales netz für multi-emulatoren in einer offenen systemumgebung | |
DE69328666T2 (de) | Verfahren und Gerät um eine Anzahl Rechner als einen einzigen Host auf dem Netz erscheinen zu lassen | |
DE69329418T2 (de) | Anrufverarbeitung in einem netz für kollaborative verarbeitung. | |
DE19882235B4 (de) | Verwendung von Web-Technologie für Teilnehmerverwaltungsaktivitäten | |
EP0825524B1 (de) | Verfahren zur Verwaltung der Benennung von Objekten | |
DE69802259T2 (de) | Verfahren und vorrichtung zur einrichtung eines anzapfpunktes in einem schaltnetzwerk | |
DE69624579T2 (de) | System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten | |
DE69032191T2 (de) | Anordnung und Verfahren zur Realisierung von Hochleistungskommunikation zwischen Softwareprozessen | |
DE69719620T2 (de) | Vorrichtung und Verfahren zur Bestimmung von Server-Cluster-Topologien | |
DE10054923B4 (de) | Verfahren zum Auffangen von Netzwerkpaketen in einem Computersystem, Computersystem zum Handhaben von Netzwerkpaketen sowie Paketauffängermodul zum Auffangen von Netzwerkpaketen in einem Computersystem | |
DE60103088T2 (de) | Verfahren zur Herstellung von Weiterleitungslisten für Netzwerkgruppe | |
DE69406013T2 (de) | Objektorientiertes netz-protokoll-konfigurationssystem | |
DE69231564T2 (de) | Gerät und Verfahren für ein föderales Namenssystem | |
DE60221030T2 (de) | Verfahren, einrichtung und rechnerprogramm für die entkapselung und verkapselung von paketen mit mehreren kopffeldern | |
DE69724877T2 (de) | Verfahren und Vorrichtung zum Betrieb einer Aggregation von Serverrechnern mittels eines Doppelzweck-Proxy-Servers | |
DE60109709T2 (de) | Datenverwaltungsrahmenwerk für Verfahrensverwaltung | |
DE69128952T2 (de) | Gerät und Verfahren zur Entkupplung von Datenaustauschdetails zur Beschaffung einer Hochleistungskommunikation zwischen Softwareprozessen | |
DE60032018T2 (de) | Verfahren und vorrichtung zur weiterleitung der proprietären daten in einer offenen architektur für netzwerkgeräte | |
DE69607142T2 (de) | Verwendung von mehrpunktverbindungsdiensten zur herstellung von rufanzapfungspunkten in einem vermittlungsnetz | |
DE60100671T2 (de) | Verfahren zum Verteilen von Diensten und Verfahren zum Konfigurieren von einem Netzelementen in einem Kommunikationsnetzwerk | |
DE60204528T2 (de) | Auflösen von virtuellen Netzwerknamen | |
DE69927285T2 (de) | Netzverwaltungssystem | |
DE69806810T2 (de) | Vorrichtung und verfahren zur übertragbarkeit von elektronischen postaddressen |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: CISCO SYSTEMS, INC., SAN JOSE, CALIF., US |