DE69828602T2 - Von heterogenen rechnersystemen mitbenutzung einer netzschnittstellenkarte - Google Patents

Von heterogenen rechnersystemen mitbenutzung einer netzschnittstellenkarte Download PDF

Info

Publication number
DE69828602T2
DE69828602T2 DE69828602T DE69828602T DE69828602T2 DE 69828602 T2 DE69828602 T2 DE 69828602T2 DE 69828602 T DE69828602 T DE 69828602T DE 69828602 T DE69828602 T DE 69828602T DE 69828602 T2 DE69828602 T2 DE 69828602T2
Authority
DE
Germany
Prior art keywords
network
network protocol
data
computer system
server
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 - Fee Related
Application number
DE69828602T
Other languages
English (en)
Other versions
DE69828602D1 (de
Inventor
A. Robert JOHNSON
E. Dwayne EBERSOLE
W. William DISNEY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unisys Corp
Original Assignee
Unisys Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Unisys Corp filed Critical Unisys Corp
Priority claimed from PCT/US1998/011201 external-priority patent/WO1998056150A1/en
Application granted granted Critical
Publication of DE69828602D1 publication Critical patent/DE69828602D1/de
Publication of DE69828602T2 publication Critical patent/DE69828602T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Description

  • HINTERGRUND
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf das Gebiet des Computer-Netzwerkbetriebs und insbesondere auf Vorrichtungen und Verfahren, die es zwei Computersystemen gestatten, über eine gemeinsam verwendete Netzwerk-Schnittstellenkarte, die auf einem von ihnen installiert ist, auf ein Netzwerk zuzugreifen.
  • Beschreibung des Standes der Technik
  • Die Fähigkeit von heterogenen Computersystemen, über ein Netzwerk miteinander zu kommunizieren, das handelsübliche und/oder proprietäre Netzwerkprotokolle verwendet, ist bekannt. Die meisten Computersysteme besitzen irgendeine Form von Netzwerk-Architektur, die es dem Computersystem ermöglicht, das Arbeiten im Netzwerk gemäß diesen Protokollen auszuführen. Eine derartige Netzwerk-Architektur umfasst typischerweise sowohl eine Systemsoftware als auch -hardware. Die 1 ist ein Blockdiagramm, das die Komponenten einer Netzwerk-Architektur darstellt, die von einem Unisys-Unternehmen-Server 10 der A-Serie verwendet wird, um mit anderen Hosts oder Knotenrechnern in einem Netzwerk 15 zu kommunizieren.
  • Der Unternehmen-Server 10 der A-Serie führt das Unisys-MCP-Betriebssystem 12 aus und besitzt ein E/A-Teilsystem, das ein oder mehrere E/A-Module (EAM) 14 umfasst, die in dem Gehäuse der A-Serie untergebracht sind. Das EAM 14 implementiert eine für Unisys proprietäre E/A-Bus-Architektur, die als CS-Bus II oder CS-Bus III (hiernach "der CS-Bus") bezeichnet wird. Eine Vielzahl von Karten-Slots, z. B. die Slots 16a–16d, wird zum Anschluss von als "Kanal-Adapter" bezeichneten Schnittstellenkarten mit dem CS-Bus bereitgestellt. Unterschiedliche Gruppen oder Käfige von Kanal-Adapter-Slots werden jeweils von einer Kanal-Verwaltungs-Einheit (Channel Manager Unit, CMU, z. B. die CMUs 18a, 18b) gesteuert. Ein EAM kann mehrere CMUs enthalten, von denen jede einen anderen Stapel von Kanal-Adapter-Karten-Slots über den CS-Bus steuert. Die CMUs verwalten die physikalischen und Datenebenen des E/A-Prozesses.
  • Kanal-Adapter-Slots, von denen jede einen oder mehrere Kanal-Adapter-Karten-Slots in dem EAM 14 einnehmen kann, stellen verschiedene Konnektivität-Lösungen für den Unternehmen-Server 10 der A-Serie bereit. Zum Beispiel liefert Unisys eine Kanal-Adapterkarte, die das Kleincomputer-Systemschnittstellen-(Small Computer System Interface, SCSI)-Protokoll zum Anschließen von SCSI-Peripheriegeräten an den Unternehmen-Server implementiert.
  • Für Netzwerk-Konnektivität liefert Unisys mehrere Kanal-Adapter, um verschiedene Protokolle für physikalische Netzwerke zu unterstützen. Diese Kanal-Adapter werden allgemein als Netzwerk-Prozessoren (NP) bezeichnet. Zum Beispiel sind die Unisys ICP22- und ICP26-Netzwerk-Prozessoren Kanal-Adapter-Slots, die das Ethernet-Netzwerkprotokoll implementieren und dazu verwendet werden können, einen Unternehmen-Server der A-Serie an ein Ethernet-Netzwerk anzuschließen. Unisys liefert ferner Netzwerk-Prozessoren für Konnektivität mit FDDI- und ATM-Netzwerken. Wie in der 1 gezeigt ist, kann eine Reihe von unterschiedlichen Netzwerk-Prozessoren (z. B. die NPs 20a, 20b und 20c) in entsprechenden Kanal-Adapter-Slota (z. B. den Slots 16b, 16c und 16d) des EAM 14 installiert werden, um unterschiedliche Netzwerk-Konnektivität-Lösungen bereitzustellen.
  • Wie in der detaillierteren Ansicht des Netzwerk-Prozessors 20c (installiert im Kanal-Adapter-Slot 16d) gezeigt ist, kann ein Netzwerk-Prozessor eine Vielzahl von unterschiedlichen Leitungen umfassen, z. B. die Leitung0, Leitung1 ... LeitungN. Eine Leitung stellt einen physikalischen Endpunkt innerhalb eines Netzwerks dar. Zum Beispiel besitzt der Unisys ICP22-Netzwerk-Prozessor zwei Leitungen, von denen jede eine separate Ethernet-Verbindung umfasst – eine Leitung könnte an ein Ethernet-Netzwerk und die andere an ein anderes Ethernet-Netzwerk angeschlossen sein.
  • Jede Leitung eines Netzwerk-Prozessors kann eine auf dieser Leitung definierte Stationsgruppe besitzen. Eine Stationsgruppe besteht aus einer oder mehreren Stationen. Eine Station ist ein logischer Endpunkt, der einen logischen Dialog auf dieser Leitung darstellt. Somit kann mehr als ein logischer Dialog über eine bestimmte Leitung eines Netzwerk-Prozessors stattfinden. Dies wird durch Senden im Multiplex-Verfahren erreicht. Zum Beispiel kann mit einem verbindungsorientierten Netzwerk-Protokoll, wie dem Protokoll Burroughs Network Architecture – Version 2 (BNAv2), eine Station einen logischen Dialog mit einem anderen BNAv2-Host im Netzwerk darstellen, während eine weitere Station einen logischen Dialog mit einem weiteren BNAv2-Host darstellen kann. Wie zum Beispiel in der 1 dargestellt ist, kann die Station0 der LeitungN einen logischen Dialog mit dem BNAv2-Host 22 darstellen, und die Station1 der LeitungN kann einen logischen Dialog mit dem BNAv2-Host 24 darstellen. Für Netzwerkprotokolle, die nicht verbindungsorientiert sind, wie das Internet Protocol (IP), muss nur eine Station definiert werden, um die gesamte Kommunikation für diesen Protokollstapel zu handhaben. Zum Beispiel könnte in der 1 die StationN der LeitungN als der logische Endpunkt für den gesamten IP-Verkehr über die LeitungN definiert werden. Ein Local Area Network Station Group (LANSG)-Modul 26, das Software umfasst, die auf dem Netzwerk-Prozessor 20c ausgeführt wird, stellt abrufbare Prozeduren zum Erstellen und Verwalten von Stationen und Stationsgruppen auf den verschiedenen Leitungen des Netzwerk-Prozessors 20d und zum Senden und Empfangen von Daten über sie bereit.
  • Andere Softwarekomponenten, die auf dem Netzwerk-Prozessor 20d ausgeführt werden, schließen ein Queue Service Provider (QSP)-Modul 28 ein, welches das Senden von Daten im Multiplex- und Demultiplex-Verfahren für alle auf einem bestimmten NP definierten Stationen handhabt, und zwei Stub-Module – ein Network Services Manager-Stub (NSM-Stub) 30 und ein Link Layer Manager-Stub (LLM-Stub) 32 – die mit entsprechenden Modulen einer Core Network Services (CNS)-Softwarekomponente 34 verbunden sind, an und von Modulen innerhalb der MCP-Umgebung.
  • Allgemein implementiert ein Netzwerk-Prozessor (z. B. das NP 20a, 20b oder 20c) die Datenverbindung und die physikalischen Ebenen des 7-Ebenen-ISO-Referenzmodells. Netzwerkprotokolle eines höheren Levels, die eine Client-Anwendung 46 möglicherweise verwenden möchte, um mit Anwendungen zu kommunizieren, die auf unterschiedlichen Hosts des Netzwerks 15 laufen, wie die BNAv2- und TCP/IP-Netzwerkprotokolle, sind als Netzwerkprotokoll-Provider auf dem System 10 der A-Serie implementiert. Ein Netzwerkprotokoll-Provider ist ein Softwaremodul, das diese Netzwerkprotokolle eines höheren Levels implementiert. Zum Beispiel stellt Unisys sowohl BNAv2-Host Resident Network Provider (HRNP)-Module als auch TCP/IP-HRNP-Module bereit. In dem Beispiel in 1 sind ein BNAv2-HRNP 42 und ein TCP/IP-HRNP 44 dargestellt.
  • Die Core Network Services (CNS)-Software 34 stellt Unterstützung für die Netzwerkprotokoll-Provider 42, 44 bereit und handhabt die Initialisierung und Verwaltung von Netzwerk-Prozessoren und den darauf definierten Stationsgruppen. Im Speziellen umfasst CNS 34 einen Network Services Manager (NSM) 36, welcher die in dem System installierten Netzwerk-Prozessoren (z. B. 20a, 20b, 20c) initialisiert und verwaltet, und einen Link Layer Manager (LLM) 38, welcher die Identität und Attribute jeder auf einem bestimmten Netzwerk-Prozessor definierten Stationsgruppe initialisiert und verwaltet. Eine weitere Komponente (nicht gezeigt) des CNS 34 validiert Attribute, die mit Stationsgruppen und Stationen assoziiert sind, die auf einem Netzwerk-Prozessor erzeugt wurden. Diese Attribute werden zwischen dem Netzwerk-Prozessor und CNS 34 über einen Steuerdialog weitergegeben, wenn die Stationen definiert werden. Ähnlich wie die Stub-Prozeduren für die NSM- und LLM-Module 36, 38, besitzen auch die Netzwerk-Prozessoren eine Stub-Prozedur (LLAH, nicht gezeigt), die dem Attribut-Handler von CNS 34 entspricht. Eine NPSUPPORT-Softwarebibliothek 40 sowie Teile des MCP-Betriebssystems 12 stellen Routinen und Prozedurenabrufe bereit, die als Schnittstelle zwischen einem Netzwerk-Prozessor und dem CNS 34 und den Netzwerkprotokoll-Providern 42, 44 dienen, und das Laden von Software zu den NPs und das Verwerfen ihres Zustands steuern.
  • Jeder Netzwerk-Prozessor besitzt eine dazugehörige Kennung, die eindeutig diesen Netzwerk-Prozessor innerhalb des Systems 10 kennzeichnet. Wenn ein Netzwerk-Prozessor initialisiert und online gebracht wird, wird das NSM-Stub 30 in dem Netzwerk-Prozessor mit dem NSM 36 von CNS 34 über einen Steuerdialog verbunden, um seine Kennung an das NSM 36 weiterzugeben. Das NSM 36 verwaltet die Kennungen sämtlicher aktiver Netzwerk-Prozessoren.
  • Jede für einen bestimmten Netzwerk-Prozessor definierte Stationsgruppe und Station besitzt ferner eine eindeutige zu ihr gehörige Kennung. Über einen zwischen dem LLM-Stub 32 auf dem Netzwerk-Prozessor und dem LLM 38 von CNS 34 hergestellten Steuerdialog werden die Stations- und Stationsgruppen-Kennungen während der Initialisierung an das LLM 38 weitergegeben. In dem LLM 38 entspricht eine Station einer Verbindung, und eine Stationsgruppe entspricht einer Verbindungsgruppe.
  • Wie oben erwähnt ist, wird die Fähigkeit, mehrere Stationen (d. h. eine Stationsgruppe) auf einer einzigen physikalischen Leitung eines Netzwerk-Prozessors zu definieren, mittels des Sendens im Multiplex-Verfahren erlangt. Im Speziellen sendet das QSP 28 in dem Netzwerk-Prozessor im Multiplex-Verfahren einkommende und ausgehende Daten für mehrere Stationen auf einer bestimmten Leitung. Außerdem ist das QSP für das Verteilen von Anforderungs- und Antwortdaten zwischen dem NSM 36 und dem NSM-Stub 30 und zwischen dem LLM 38 und dem LLM-Stub 32 zuständig. Zu diesem Zweck wird jeder Entität auf dem Netzwerk-Prozessor, die ausgehende Daten von dem MCP empfängt, einschließlich jeder Station, des NSM-Stubs 30 und des LLM-Stubs 32, von dem QSP eine eindeutige Remote Queue Reference (RQR) zugewiesen. Die NSM-Stub-RQR wird an das NSM 36 in CNS 34 über NPSUPPORT gemeldet, wenn das NP geladen wird. Die LLM-Stub-RQR wird über das NSM 36 von dem NSM-Stub 30 an das LLM 38 gemeldet, wenn das NP initialisiert wird. Sämtliche Stations-RQRs werden an die HRNPs gemeldet, während sich die Stationen öffnen.
  • Wenn es erforderlich ist, dass eine Client-Anwendung Daten über das Netzwerk 15 zu irgendeinem anderen Host oder Knotenrechner im Netzwerk 15 sendet, wie z. B. zu einem anderen BNAv2-Host oder einem anderen TCP/IP-Host, ruft sie die Dienste des geeigneten Netzwerkprotokoll-Providers, z. B. 42, 44, auf. Der Netzwerkprotokoll-Provider 42, 44 bestimmt den geeigneten Netzwerk-Prozessor und die Station, auf der die Daten ausgegeben werden sollen, fügt Protokoll-Kopfzeilen hinzu und führt eine entsprechende Anforderung an das MCP 12 durch, welche die Kennung des Netzwerk-Prozessors und die RQR der Station einschließt. Die Daten und die dazugehörige RQR werden aus dem MCP 12 an das QSP 28 im Netzwerk-Prozessor (z. B, dem Netzwerk-Prozessor 20c) weitergegeben, das, in Kombination mit dem LANSG-Modul 26, die Daten als Teil des logischen Dialogs, der durch die designierte Station repräsentiert wird, über die geeignete Leitung (z. B. die Leitung0, Leitung1, ... oder LeitungN) hinaus an das Netzwerk 15 sendet.
  • Wenn Daten aus dem Netzwerk 15 auf einer bestimmten Leitung empfangen werden, bestimmt das LANSG-Modul 26 aus der zu den Daten gehörigen Kopfzeilen-Information die Station (d. h, den logischen Dialog), für welche die Daten bestimmt sind. Die LANSG- und QSP-Module 26, 28 geben in Kombination mit Teilen des MCP 12 und der NPSUPPORT-Bibliothek 40 die empfangenen Daten an den geeigneten zu dieser Station gehörigen Netzwerkprotokoll-Provider 42, 44 weiter, zusammen mit einer Angabe, welche Station die Daten empfangen hat. Zum Beispiel kann eine der Stationen auf der LeitungN des Netzwerk-Prozessors 20c in 1 (z. B. die Station0) als der logische Endpunkt für das BNAv2-HRNP 42 definiert werden, während eine andere Station (z. B. die Station1) als der logische Endpunkt definiert werden kann, auf dem der gesamte IP-Verkehr für das TCP/IP-HRNP 44 über die LeitungN empfangen wird. Wenn ein Daten-Rahmen aus dem Netzwerk an der LeitungN empfangen wird, bestimmt das LANSG-Modul 26 aus der Kopfzeilen-Information, welcher der Netzwerkprotokoll-Provider (d. h. der Stationen) dazu bestimmt ist, die Daten zu empfangen. Diese Bestimmung wird gemäß den Verfahren ausgeführt, die in dem US-Patent Nr. 5,379,296 mit dem Titel "Method and Apparatus for Interfacing a Workstation to a Plurality of Computer Platforms" (Johnson u. a.) beschrieben sind, das auf den Inhaber des vorliegenden Patents übertragen wurde.
  • Zusätzlich zu ihrer Verwendung in Computern der A-Serie wird die obige Netzwerk-Architektur ferner in Unisys ClearPath HMP NX-Unternehmen-Servern verwendet. Ein ClearPath HMP NX- Server umfasst einen Unternehmen-Server der A-Serie, der mit einem Server fest integriert ist, auf dem Microsoft Windows NT läuft. Man beachte, dass "Microsoft", "Windows" und "Windows NT" registrierte Marken der Microsoft Corporation sind. Zusätzliche Informationen, welche die obige Netzwerk-Architektur betreffen, sind in den folgenden Dokumenten zu finden, von denen jedes bei der Unisys Corporation erhältlich ist, dem Inhaber der vorliegenden Erfindung, und von denen hiermit jedes vollständig durch die Bezugnahme eingeschlossen ist:
    • ClearPath HMP NX Series with Windows NT Network Services Implementation Guide (Art. Nr. 4198 6670);
    • BNA/CNS Network Implementation Guide. Volume 2: Configuration (Art. Nr. 3789 7014);
    • ClearPath HMP NX Series with Windows NT Implementations and Operations Guide (Art. Nr. 8807 6542);
    • ClearPath HMPNXSeHes with Windows NTMigmtion Guide (Art. Nr. 8807 7730);
    • Networking Capabilities Overview (Art. Nr. 3789 7139)
    • Networking Operations Reference Manual Volumes 1 and 2. Commands and Inquiries (Art. Nr. 3787 7917); und
    • Networking Products Installation Guide (Art. Nr. 4198 4840).
  • Unter Verwendung eines Unisys ICP22-Netzwerk-Prozessors, der einen Ethernet-basierten Kanal-Adapter darstellt, war es für einen Unisys-Unternehmen-Server der A-Serie in der Vergangenheit möglich, mit einer Datenstation oder einem Personal-Computer (PC) über ein Netzwerk zu kommunizieren. Ein Beispiel für diese Fähigkeit ist in der 2 dargestellt. In diesem Beispiel kommuniziert der Unternehmen-Server 10 der A-Serie mit einer Intel-basierten Datenstation 48, auf der das Microsoft Windows NT-Betriebssystem (im Folgenden "der NT-Server") läuft. Der Unternehmen-Server der A-Serie ist mit dem Netzwerk über den Netzwerk-Prozessor 20a verbunden, der zum Beispiel ein Ethernetbasierter Unisys ICP22-Netzwerk-Prozessor sein kann.
  • Das E/A-Teilsystem des NT-Servers 48 umfasst Teile des NT-Betriebssystem-Kernels, einen EISA- oder PCI-Bus 52 und geeignete Gerätetreibersoftware. Um Netzwerk-Konnektivität bereitzu stellen, wird eine Netzwerk-Schnittstellenkarte (network Interface card, NIC) 50 in einem verfügbaren Bus-Slot auf dem NT-Server 48 installiert. Der NT-Server kann einen oder beide der PCI- und EISA-Bus-Standards unterstützen. NICs sind für beide Bus-Standards erhältlich.
  • Ein NIC-Gerätetreiber 54, der typischerweise mit der NIC-Karte 50 verkauft wird, wird in dem Kernel-Raum des NT-Betriebssystems installiert. Der NIC-Gerätetreiber 54 ist mit einem Provider für ein Netzwerkprotokoll eines höheren Levels verbunden, wie z. B. mit einer Implementierung des TCP/IP-Protokolls. Die Microsoft Corporation liefert eine Implementierung des TCP/IP-Protokolls in Form eines Gerätetreibers auf Kernelebene, der auch als Transportprotokoll-Treiber bezeichnet wird, genannt TCPIP.SYS 58. Der TCPIP.SYS 58 wird mit dem NIC-Gerätetreiber 54 über NDIS verbunden, eine Industriestandard-Netzwerktreiber-Schnittstellenspezifikation, die von Microsoft und 3Com gemeinsam entwickelt wurde. NDIS definiert eine Schnittstelle für die Kommunikation zwischen Hardwareunabhängigen Protokolltreibern, wie z. B. TCPIP.SYS, welche die Datensicherungs-, Vermittlungs- und Transportschichten des OSI-Modells implementieren, und Hardware-abhängigen NIC-Treibern, die eine Schnittstelle zur NIC-Hardware bereitstellen und die der physikalischen Schicht des OSI-Modells entsprechen. Ein Client-Programm 60 auf dem NT-Server kann gemäß dem TCP/IP-Protokoll über das Netzwerk 15 durch Ausgabe geeigneter Aufrufe an den TCPIP.SYS-Protokolltreiber über das NT-Betriebssystem kommunizieren.
  • Netzwerk-Schnittstellenkarten und dazugehörige Gerätetreiber für NT-Server sind bei einer Reihe von Herstellern von Originalausstattung (Original Equipment Manufacturers, OEMs) erhältlich. OEM-NICs sind zu verhältnismäßig niedrigen Kosten für eine Vielzahl von unterschiedlichen Netzwerk-Medienstandards erhältlich, einschließlich Ethernet, Fast-Ethernet usw. Während sich neue Netzwerk-Standards herausbilden, müssen OEMs NICs schnell entwerfen und herstellen, um diese Standards zu unterstützen. Weil diese NICs für E/A-Bus-Architekturen mit Industriestandard entwickelt werden, wie z. B. EISA und PCI, die heute in den vielen Computersystemen gefunden werden, resultiert die Kostendegression in Entwicklungszeiten mit schnellem Zyklus und außerordentlich niedrigen Verbraucherpreisen.
  • Im Gegensatz dazu dauert es wesentlich länger und kostet wesentlich mehr, einen neuen Netzwerk-Prozessor für eine proprietäre Bus-Architektur zu entwerfen und herzustellen, wie z. B. die CS-BUS II-Architektur der Unisys-Unternehmen-Server der A-Serie. Anbieter von proprietären Systemen können nicht die gleiche Kostendegression erzielen wie die Anbieter von NICs für offene Systeme, und Netzwerk-Prozessoren oder NICs für proprietäre Systeme kosten deswegen typischerweise wesentlich mehr als ihre Gegenstücke für offene Systeme. Um die Kosten zu vermeiden, die mit der Entwicklung von NICs für proprietäre Systeme zusammenhängen, wäre es wünschenswert, wenn es für zwei Computersysteme möglich wäre, dass jedes über eine gemeinsam verwendete Netzwerk-Schnittstellenkarte, die auf einem der Systeme installiert ist, auf ein Netzwerk zugreift. Die vorliegende Erfindung stellt eine derartige Fähigkeit bereit.
  • Die WO 97 01944 beschreibt einen Mechanismus, der es emulierten Umgebungen innerhalb eines Host-Computersystems ermöglicht, einen einzigen TCP/IP-Protokollstapel mit dem Host-System gemeinsam zu verwenden, aber sie lehrt nicht oder schlägt nicht einen Mechanismus vor, der es zwei Host-Umgebungen, von denen jede ihren eigenen Protokollstapel besitzt, ermöglicht, eine einzige Netzwerk-Schnittstellenkarte gemeinsam zu verwenden, die sich in einem der Systeme befindet. Der in der WO 97 01944 beschriebene Mechanismus bezieht sich nicht auf das gleiche Problem wie die vorliegende Erfindung.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung ist auf Verfahren und Vorrichtungen ausgerichtet, die es einem ersten Netzwerkprotokoll-Provider, der auf einem ersten Computersystem ausgeführt wird und eine damit verknüpfte erste Netzwerkadresse besitzt, und einem zweiten Netzwerkprotokoll-Provider, der auf einem zweiten Computersystem ausgeführt wird und eine damit verknüpfte zweite Netzwerkadresse besitzt, ermöglichen, Daten über ein Netzwerk mit tels derselben Netzwerk-Schnittstellenkarte, die auf dem zweiten Computersystem installiert ist, sowohl zu senden als auch zu empfangen. Gemäß einer bevorzugten Ausführungsform davon umfasst die vorliegende Erfindung eine Verbindung, die das Eingabe/Ausgabe-(E/A)-Teilsystem des ersten Computersystems mit dem (E/A)-Teilsystem des zweiten Computersystems verbindet und über die Daten zwischen Systemen übertragen werden können, und einen Router, der auf dem zweiten Computersystem ausgeführt wird und Daten zwischen dem ersten Netzwerkprotokoll-Provider (über die Verbindung), dem zweiten Netzwerkprotokoll-Provider und der Netzwerk-Schnittstellenkarte auf eine Art und Weise routet, die es der Netzwerk-Schnittstellenkarte ermöglicht, vom ersten und zweiten Netzwerkprotokoll-Provider gemeinsam verwendet zu werden. Im Speziellen routet der Router, wenn von der Netzwerk-Schnittstellenkarte Daten aus dem Netzwerk empfangen werden, die Daten über die Verbindung an den ersten Netzwerkprotokoll-Provider, wenn eine mit den Daten empfangene Netzwerkadresse mit der ersten Netzwerkadresse übereinstimmt, gibt aber die empfangenen Daten an den zweiten Netzwerkprotokoll-Provider weiter, wenn die mit den Daten empfangene Netzwerkadresse mit der zweiten Netzwerkadresse übereinstimmt. Von dem Netzwerk empfangene Daten mit einer Broadcast-Adresse werden sowohl an den ersten (über die Verbindung) als auch den zweiten Netzwerkprotokoll-Provider geroutet. Ausgehende Daten von jedem Netzwerkprotokoll-Provider werden an das Netzwerk über dieselbe Netzwerk-Schnittstellenkarte geroutet. Wenn jedoch ausgehende Daten von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider an den anderen Netzwerkprotokoll-Provider adressiert werden, ermöglicht es eine "Prüfschleifen"-Fähigkeit dem Router, diese Daten direkt von einem Netzwerkprotokoll-Provider zum anderen zu routen, wobei er die Netzwerk-Schnittstellenkarte umgeht. Ferner werden von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider ausgehende Daten, die eine Broadcast-Adresse besitzen, an das Netzwerk über die Netzwerk-Schnittstellenkarte und ferner über den "Prüfschleifen"-Pfad an den anderen Netzwerkprotokoll-Provider (wobei die Netzwerk-Schnittstellenkarte umgangen wird) geroutet. In sämtlichen Fällen werden die zwischen dem ersten und dem zweiten Computersystem gerouteten Daten über die Verbindung übertragen. Zusätzlich versteht sich, dass die vorliegende Erfindung verwendet werden kann, um Daten an und von einer Vielzahl von Netzwerkprotokoll-Providern auf dem ersten Computersystem und/oder einer Vielzahl von Netzwerkprotokoll-Providern auf dem zweiten System über dieselbe Netzwerk-Schnittstellenkarte zu routen.
  • Vorzugsweise simuliert der Router den Betrieb eines Netzwerkprotokoll-Providers, wenn er mit einem Gerätetreiber der Netzwerk-Schnittstellenkarte verbunden ist, und der Router simuliert den Betrieb eines Gerätetreibers der Netzwerk-Schnittstellenkarte, wenn er mit dem ersten und zweiten Netzwerkprotokoll-Provider verbunden ist, wobei die Funktionalität des Routers für die Netzwerk-Schnittstellenkarte und den ersten und zweiten Netzwerkprotokoll-Provider transparent ist.
  • Die Verbindung zwischen dem E/A-Teilsystem des ersten Computersystems und dem E/A-Teilsystem des zweiten Computersystems umfasst vorzugsweise eine physikalische Verbindung zwischen den E/A-Teilsystemen, über die Daten zwischen ihnen übertragen werden können, und einen Verbindung-Gerätetreiber auf dem zweiten Computersystem, der den Zugriff von dem zweiten Computersystem auf die physikalische Verbindung steuert. Die Schnittstelle zwischen dem Verbindung-Gerätetreiber und anderen Komponenten im zweiten Computersystem wird vorzugsweise in Form eines Prozedur-Registrierungsmechanismus implementiert. Auf diese Art und Weise können unterschiedliche Verbindung-Gerätetreiber für unterschiedliche physikalische Verbindungen auf dem zweiten Computersystem in einer Art und Weise installiert werden, die für die anderen Komponenten der vorliegenden Erfindung transparent ist. Wenn zum Beispiel das erste und das zweite Computersystem separate physikalische Einheiten sind, kann die physikalische Verbindung geeignete Hardware (z. B. Schnittstellenkarten), die in verfügbaren Slots der E/A-Busse jedes Systems installiert ist, und ein Kabel umfassen, das eine Verbindung zwischen ihnen bereitstellt. Alternativ kann, wenn das erste Computersystem innerhalb des zweiten Systems emuliert ist, die physikalische Verbindung innerhalb des zweiten Systems in Form einer Speicher-zu-Speicher-Verbindung emuliert werden. Ein Vorteil der vorliegenden Erfindung besteht darin, dass sie verwendet werden kann, um es einem Computersystem, das ein proprietäres E/A-Teilsystem besitzt, zu ermöglichen, über eine Standard-Netzwerk-Schnittstellenkarte auf ein Netzwerk zuzugreifen, die für ein offeneres oder verbreitet verwendetes E/A-Teilsystem entwickelt wurde, wie z. B. das, welches in Systemen zu finden ist, die das Microsoft Windows NT-Betriebssystem unterstützen. Dadurch wird die Notwendigkeit vermieden, Netzwerk-Schnittstellenkarten für das proprietäre System zu entwickeln, während sich neue Netzwerkprotokolle und Standards herausbilden. Stattdessen gestattet es die vorliegende Erfindung dem proprietären System, Netzwerk-Schnittstellenkarten gemeinsam zu verwenden, die für das offene System entworfen wurden.
  • Zusätzliche Merkmale und Vorteile der vorliegenden Erfindung werden im folgenden ersichtlich.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorangegangene Zusammenfassung sowie die folgende detaillierte Beschreibung der bevorzugten Ausführungsform ist besser zu verstehen, wenn sie in Verbindung mit den angefügten Zeichnungen gelesen wird. Für den Zweck der Erläuterung der Erfindung wird in den Zeichnungen eine Ausführungsform gezeigt, die derzeit bevorzugt wird, wobei es sich jedoch versteht, dass die Erfindung nicht auf die offenbarten spezifischen Verfahren und Einrichtungen beschränkt ist. In den Zeichnungen:
  • ist die 1 ein Blockdiagramm, das die Komponenten einer Netzwerk-Architektur des Standes der Technik darstellt, die von Unisys-Unternehmen-Servern der A-Serie verwendet wird, um mit anderen Hosts oder Knotenrechnern auf einem Netzwerk zu kommunizieren;
  • ist die 2 ein Blockdiagramm, das ein Verfahren des Standes der Technik zeigt, durch das ein Unisys-Unternehmen-Server der A-Serie über ein Netzwerk mit einem Server kommunizieren kann, auf dem Microsoft Windows NT läuft;
  • ist die 3 ein Blockdiagramm, das gemäß der vorliegenden Erfindung eine Ausführungsform eines Geräts darstellt, das es zwei Computersystemen ermöglicht, eine einzige Netzwerk-Schnittstellenkarte gemeinsam zu verwenden, die auf einem von ihnen installiert ist;
  • ist die 4 ein Blockdiagramm, das eine alternative Ausführungsform einer Verbindung der Vorrichtung in 3 darstellt;
  • ist die 5 ein Blockdiagramm, das noch eine weitere Ausführungsform der Verbindung der Vorrichtung in 3 darstellt;
  • sind die 6A–F Flussdiagramme, die den Betrieb der in den 3–5 dargestellten Verbindungen genauer darstellen;
  • ist die 7 ein Diagramm, das die unterschiedlichen Datenpfade darstellt, über die der Router der vorliegenden Erfindung ankommende und ausgehende Netzwerkdaten routen kann;
  • ist die 8 ein Blockdiagramm, das gemäß einer bevorzugten Ausführungsform weitere Details einer Implementierung des Routers der vorliegenden Erfindung darstellt;
  • umfassen die 9A–9C eine Pseudocode-Auflistung, die weitere Details einer Ausführungsform der Routing-Funktionalität des Routers der vorliegenden Erfindung und ferner eine Ausführungsform eines Verfahrens der vorliegenden Erfindung darstellt;
  • sind die 10A–D Flussdiagramme, die weitere Details einer weiteren Ausführungsform der Routing-Funktionalität des Routers der vorliegenden Erfindung und ferner eine weitere Ausführungsform des Verfahrens der vorliegenden Erfindung darstellen.
  • DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Die vorliegende Erfindung ist auf Verfahren und Vorrichtungen ausgerichtet, die es einem ersten Netzwerkprotokoll-Provider, der auf einem ersten Computersystem ausgeführt wird und eine damit verknüpfte erste Netzwerkadresse besitzt, und einem zweiten Netzwerkprotokoll-Provider, der auf einem zweiten Computersystem ausgeführt wird und eine damit verknüpfte zweite Netzwerkadresse besitzt, ermöglichen, Daten über ein Netzwerk mittels derselben Netzwerk-Schnittstellenkarte, die im zweiten Computersystem installiert ist, sowohl zu senden als auch zu empfangen. Gemäß einer bevorzugten Ausführungsform davon umfasst die vorliegende Erfindung eine Verbindung, die das Eingabe/Ausgabe-(E/A)-Teilsystem des ersten Computersystems mit dem E/A-Teilsystem des zweiten Computersystems verbindet und über die Daten zwischen Systemen übertragen werden können, und einen Router, der auf dem zweiten Computersystem ausgeführt wird, der Daten zwischen dem ersten Netzwerkprotokoll-Provider (über die Verbindung), dem zweiten Netzwerkprotokoll-Provider und der Netzwerk-Schnittstellenkarte auf eine Art und Weise routet, die es der Netzwerk-Schnittstellenkarte ermöglicht, vom ersten und zweiten Netzwerkprotokoll-Provider gemeinsam verwendet zu werden.
  • In einer Ausführungsform, die hiernach ausführlicher beschrieben wird, können die Verfahren und Vorrichtungen der vorliegenden Erfindung als Teil einer kooperativen Netzwerk-Plattform (Cooperative Networking Platform, CNP, manchmal auch als "NX/Netzwerk-Dienste" oder "NNS" bezeichnet) implementiert werden, die als ein Merkmal von Unisys ClearPath HMP NX-Unternehmen-Servern bereitgestellt wird, in denen, wie oben erwähnt ist, ein Unisys-Unternehmen-Server der A-Serie mit einem Intel-basierten Server fest integriert ist, auf dem Microsoft Windows NT läuft. In dieser Ausführungsform umfasst der Unternehmen-Server der A-Serie das erste Computersystem und der NT-Server umfasst das zweite Computersystem. Wie in dieser Umgebung ausgeführt, gestattet es die vorliegende Erfindung einem Netzwerkprotokoll-Provider (z. B. BNAv2 HRNP oder TCP/IP HRNP) auf dem Server der A-Serie, Daten über ein Netzwerk mittels einer in dem NT-Server installierten Standard-Netzwerk-Schnittstellenkarte zu senden und zu empfangen. Ein Netzwerkprotokoll-Provider (z. B. TCPIP.SYS) auf dem NT-Server kann ebenfalls über diese NIC auf das Netzwerk zugreifen, und somit wird die NIC von beiden Systemen gemeinsam verwendet. Diese Fähigkeit ist vorteilhaft, weil NICs für NT-Server weit verbreitet zu verhältnismäßig niedrigen Kosten erhältlich sind. Die Notwendigkeit, proprietäre NICs (d. h. Netzwerk-Prozessoren) für den Server der A-Serie zu entwickeln, und die damit verbundenen erheblichen Kosten können vermieden werden.
  • Die Verfahren und Vorrichtungen der vorliegenden Erfindung oder bestimmte Aspekte oder Teile davon können die Form von einem Programmcode (d. h. von Anweisungen) annehmen, der in greifbaren Medien verkörpert sind, wie Floppy-Disketten, CD-ROMs, Festplatten oder einem beliebigen anderen maschinenlesbaren Speichermedium, worin, wenn der Programmcode in eine Maschine, wie z. B. einen Computer, geladen und von ihr ausgeführt wird, die Maschine zu einem Gerät zum Ausüben der Erfindung wird. Die Verfahren und Vorrichtungen der vorliegenden Erfindung können ferner in Form eines Programmcodes verkörpert werden, der über ein beliebiges Übertragungsmedium übertragen wird, wie z. B. über elektrische Verdrahtung oder Verkabelung, über Glasfaseroptik oder über irgendeine andere Form von Übertragung, worin, wenn der Programmcode von einer Maschine empfangen und in sie geladen und ausgeführt wird, wie in einem Computer, die Maschine zu einem Gerät für die Ausübung der Erfindung wird. Wenn er auf einem Allzweck-Prozessor implementiert wird, vereinigt sich der Programmcode mit dem Prozessor, um ein einzigartiges Gerät bereitzustellen, das analog zu spezifischen logischen Schaltkreisen arbeitet.
  • Bezug nehmend auf die Zeichnungen, worin gleiche Ziffern durchweg gleiche Elemente repräsentieren, ist die 3 ein Blockdiagramm, das eine Ausführungsform der vorliegenden Erfindung darstellt, in der die Verfahren und Vorrichtungen der vorliegenden Erfindung als Teil einer kooperativen Netzwerk-Plattform (CNP) implementiert sind, die auf einem Unisys Clear Path HMP NX-Computersystem (dem "C1earPath-System") eingesetzt wird. Wie gezeigt ist, umfasst das ClearPath-System einen Unisys-Unternehmen-Server 100 der A-Serie und einen Intelbasierten Server 102, auf dem Windows NT 102 läuft (der "NT-Server"). In dieser Ausführungsform definiert der Unternehmen-Server 100 der A-Serie ein erstes Computersystem und der NT-Server 102 definiert ein zweites Computersystem. Ein erster Netzwerkprotokoll-Provider 44 wird auf dem System 100 der A-Serie bereitgestellt, in diesem Fall ein TCP/IP-HRNP, und er besitzt eine mit ihm verknüpfte Netzwerkadresse (d. h. eine IP-Adresse). Ein zweiter Netzwerkprotokoll-Provider 58 wird auf dem NT-Server. 102 bereitgestellt, in diesem Fall ein TCPIP.SYS (erhältlich bei der Microsoft Corporation), und er besitzt seine eigene mit ihm verknüpfte Netzwerkadresse (d. h. eine IP-Adresse), die eine zweite Netzwerkadresse in dieser Ausführungsform definiert. Andere Netzwerkprotokoll-Provider können auf den Servern der A-Serie und den NT-Servern auch installiert werden. Zum Beispiel kann auf dem Server der A-Serie ein BNAv2 HRNP 42 bereitgestellt werden. Es ist jedoch zu beachten, dass, weil das BNAv2-Protokoll ein proprietäres Unisys-Protokoll ist, das BNAv2 HRNP 42 keine mit ihm verknüpfte IP-Adresse besitzt. Eine Netzwerk-Schnittstellenkarte (NIC) 50 ist in einem Slot des E/A-Busses (z. B. dem EISA oder PCI) des NT-Servers 102 installiert. In dieser Ausführungsform kann eine beliebige NIC des LAN-Typs verwendet werden, die mit Windows NT kompatibel ist. Vorzugsweise unterstützt die NIC das Fast-Ethernet-Netzwerkprotokoll (z. B. das 100Base-T). NICs dieses Typs sind bei zahlreichen Lieferanten und Herstellern von Originalausstattung (OEMs) erhältlich. NICs, die andere Arten von physikalischen Medien unterstützen, wie das Ethernet/802.3, FDDI oder Gigabit-Ethernet, können alternativ verwendet werden. Typischerweise liefert ein NIC-Anbieter mit der NIC einen Gerätetreiber, der in dem Kernel-Raum des Betriebssystems installiert ist, so dass andere Entitäten auf dem System auf die Netzwerk-Funktionalität der NIC zugreifen können. Die NIC 50 des exemplarischen Systems in 3 besitzt einen Gerätetreiber 54 ("<nicdrv>.sys"), der in dem Windows NT-Kernel-Raum installiert ist, wie gezeigt.
  • Gemäß der vorliegenden Erfindung werden Vorrichtungen und Verfahren bereitgestellt, die es sowohl dem ersten als auch dem zweiten Netzwerkprotokoll-Provider 44, 58 ermöglichen, auf das Netzwerk 15 über dieselbe NIC 50 zuzugreifen, die im zweiten Computersystem 102 installiert ist. Das bedeutet, dass die vorliegende Erfindung es der NIC 50 ermöglicht, von den beiden Systemen 100, 102 gemeinsam verwendet zu werden.
  • Die Vorrichtung der vorliegenden Erfindung umfasst eine Verbindung, die das E/A-Teilsystem des Servers 100 der A-Serie mit dem E/A-Teilsystem des NT-Servers 102 verbindet, so dass Daten zwischen den zwei Servern übertragen werden können, und einen Router 80, der auf dem zweiten Computersystem (d. h. dem NT-Server 102) ausgeführt wird. Der Router 80 routet Daten zwischen dem ersten Netzwerkprotokoll-Provider (über die Verbindung), dem zweiten Netzwerkprotokoll-Provider und der NIC 50, so dass die NIC 50 von beiden Netzwerkprotokoll-Providern gemeinsam verwendet werden kann. Im Speziellen routet der Router 80, wenn von der NIC 50 Daten aus dem Netzwerk 15 empfangen werden, die Daten an den ersten Netzwerkprotokoll-Provider (z. B. das TCP/IP HRNP 44) über die Verbindung, wenn eine mit den Daten empfangene Netzwerkadresse mit der ersten Netzwerkadresse übereinstimmt, gibt aber die empfangenen Daten an den zweiten Netzwerkprotokoll-Provider (z. B. das TCPIP.SYS 58) weiter, wenn die mit den Daten empfangene Netzwerkadresse mit der zweiten Netzwerkadresse übereinstimmt. Die aus dem Netzwerk 15 mit einer Broadcast-Adresse empfangenen Daten werden sowohl an den ersten (über die Verbindung) als auch an den zweiten Netzwerkprotokoll-Provider geroutet. Von jedem Netzwerkprotokoll-Provider ausgehende Daten werden an das Netzwerk 15 über ebendiese NIC 50 geroutet. Wenn jedoch von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider ausgehende Daten an den anderen Netzwerkprotokoll-Provider adressiert werden, ermöglicht es eine "Prüfschleifen"-Fähigkeit dem Router 80, diese Daten direkt von einem Netzwerkprotokoll-Provider an den anderen zu routen, wobei er die NIC 50 umgeht. Ferner werden von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider ausgehende Daten, die eine Broadcast-Adresse besitzen, über die gemeinsam verwendete NIC 50 an das Netzwerk 15 und ferner über den "Prüfschleifen"-Pfad an den anderen Netzwerkprotokoll-Provider (wobei die NIC 50 umgangen wird) geroutet.
  • Die vorliegende Erfindung ist nicht auf die Verwendung mit nur einem Netzwerkprotokoll-Provider auf jedem System beschränkt. Vielmehr kann die vorliegende Erfindung verwendet werden, um Daten an und von mehreren Netzwerkprotokoll-Providern auf jedem System zu routen, wobei jeder Netzwerkprotokoll-Provider seine eigene Netzwerkadresse besitzt. Eingehende Daten werden basierend auf der empfangenen Netzwerkadresse an den geeigneten Netzwerkprotokoll-Provider geroutet. Zusätzlich dazu, dass er in der Lage ist, Daten an die TCP/IP-Netzwerkprotokoll-Provider (z. B. das TCP/IP HRNP 44) auf dem Server 100 der A-Serie zu routen, ist der Router 80 in der vorliegenden Ausführungsform ferner dazu fähig, eingehende Daten zu routen, die an Netzwerkprotokoll-Provider adressiert sind, die das BNAv2-Netzwerkprotokoll (z. B, das BNAv2 HRNP 42) unterstützen, wie hiernach weiter beschrieben wird.
  • Zusätzliche Details der Verbindung und des Routers 80 werden im folgenden geliefert.
  • I. DIE VERBINDUNG
  • Wie oben erwähnt ist, verbindet die Verbindung der Vorrichtung der vorliegenden Erfindung das E/A-Teilsystem des Servers 100 der A-Serie mit dem E/A-Teilsystem des NT-Servers 102, um einen Datenpfad mit verhältnismäßig hoher Geschwindigkeit zwischen Systemen bereitzustellen. Vorzugsweise umfasst die Verbindung eine physikalische Verbindung zwischen den E/A-Teilsystemen des ersten und des zweiten Computers und einen Verbindung-Gerätetreiber 70, der den Zugriff auf die physikalische Verbindung über andere Softwaremodule auf dem NT-Server steuert.
  • A. Eine Ausführungsform
  • In der Ausführungsform in 3 umfasst die physikalische Verbindung eine Durchführungskarte 62, die in einem Kanal-Adapter-Slot des Servers 100 der A-Serie installiert ist, eine EISA-Personal-Computer-Kanal-Adapter-(EISA Personal Computer Channel Adapter, EPCCA)-Karte 66, die in einem EISA-Slot des E/A-Busses des NT-Servers 102 installiert ist, und ein CS-BUS II-Kabel, das den CS-BUS II des Systems der A-Serie mit der EPCCA-Karte 66 mittels der Durchführungskarte 62 verbindet. Der Verbindung-Gerätetreiber (interconnection device driver, ICD) 70 ist in dem Kernel-Raum des NT-Betriebssystems installiert. Er steuert den Zugriff auf die physikalische Verbindung (speziell die EPCCA-Karte 66) über andere Module auf dem NT-Server.
  • Obwohl es nicht in jeder Ausführungsform der vorliegenden Erfindung notwendig ist, umfasst in der in 3 dargestellten Ausführungsform die Verbindung ferner mehrere Module, die zu ähnlich bezeichneten Komponenten in der herkömmlichen Unisys-Netzwerk-Architektur analog sind, die in der 1 dargestellt und in dem Abschnitt "Hintergrund" dieser Beschreibung beschrieben ist. Diese Module schließen ein Warteschlangen-Dienst-Provider-Modul 76, das analog zu dem QSP 28 in 1 arbeitet, ein LANSG-Modul 78, das analog zu dem LANSG-Modul 26 in 1 arbeitet, und NSM-Stub- und LLM-Stub-Module 84, 86 ein, die analog zu den entsprechenden Komponenten 30, 32 in 1 arbeiten. Zusätzlich werden LDM- und LLAH-Module 82, 88 bereitgestellt, die analog zu den ähnlich bezeichneten Komponenten (nicht gezeigt) in einer herkömmlichen Unisys-Netzwerk-Architektur arbeiten. In Kombination mit der physikalischen Verbindung (d. h. der Durchführungskarte 62, dem Kabel 64 und der EPCCA-Karte 66) und dem Verbindung-Gerätetreiber 70 simulieren diese Module einen herkömmlichen Kanal-Adapter-basierten Netzwerk-Prozessor des oben beschriebenen und in der 1 dargestellten Typs. Auf diese Art und Weise werden die Merkmale und Vorteile der vorliegenden Erfindung mit verhältnismäßig geringer Veränderung der Netzwerk-Komponenten (z. B. dem CNS 34, NPSUPPORT 40, MCP 12 usw.) auf dem Server 100 der A-Serie erzielt. Mit der Ausnahme der Module LDM 82, NSM-Stub 84, LLM-Stub 86 und LLAH 88 werden die Hauptkomponenten der Verbindung als Windows NT Kernel-Ebenen-Gerätetreiber implementiert, um unnötige Datenkopien zu vermeiden, die sich ansonsten ereignen würden, wenn Daten von dem NT-Kernel-Raum zu dem Benutzerbereich übertragen würden. Jedes der oben stehenden Komponenten und Module der Verbindung wird unten detaillierter beschrieben.
  • 1. EPCCA-Karte 66
  • Die EISA-Personal-Computer-Kanal-Adapter-(EISA Personal Computer Channel Adapter, EPCCA)-Karte 66 wird in einen verfügbaren EISA-Bus-Slot in dem NT-Server 102 eingesteckt. Die EPCCA-Karte 66 überbrückt den EISA-Bus auf dem NT-Server 102 mit dem CS-BUS II des Servers 100 der A-Serie mittels des Kabels 64 und der Durchführungskarte 62. Die Durchführungskarte 62 wird in einen verfügbaren Kanal-Adapter-Slot in dem EAM 14 eingesteckt und stellt so eine direkte Verbindung zu den Daten- und Steuerleitungen des CS-BUS II bereit. Der Mikrocode auf der EPCCA-Karte 66 emuliert einen Kanal-Adapter der A-Serie.
  • 2. Verbindung-Gerätetreiber 70 (PCCA 72 und OPENCA 74)
  • In der vorliegenden Ausführungsform umfasst der Verbindungs-Gerätetreiber 70 einen PCCR-Gerätetreiber 72 und einen OPENCA-Gerätetreiber 74. Der PCCA-Treiber 72 initialisiert, schließt ab, konfiguriert und kommuniziert mit dem EPCCA-Hardware/Mikrocode 66. Der PCCA-Treiber 72 wechselwirkt mit dem OPENCA-Treiber 74 über eine Verfahrensschnittstelle. Diese Verfahrensschnittstelle überträgt 32-Byte-E/A-Nachrichten (EAMs) zwischen der EPCCA-Karte 66 und dem OPENCA 74.
  • Der OPENCA-Treiber 74 wirkt zwischen dem PCCA 72 und dem Rest der Komponenten der Verbindung als Vermittler und stellt außerdem Controller-Funktionen für den Datenpfad bereit. Er interpretiert über den PCCA-Treiber 72 und die EPCCA-Karte 66 von dem Server 100 der A-Serie erhaltene Befehle, erzeugt Ergebnisse und richtet Speicherdeskriptoren zum Bewegen von Daten zwischen dem NT-Server 102 und dem Server 100 der A-Serie ein. Das OPENCA ist mit dem QSP-Modul 76 über eine Verfahrensschnittstelle verbunden; das EAM-basierte API, das von dem PCCA-Treiber 66 verwendet wird, ist vor dem QSP 76 und anderen Modulen der Verbindung verborgen.
  • 3. Warteschlangen-Dienst-Provider (Queue Service Provider, QSP) 76
  • Das QSP 76 stellt eine Nachrichten-Warteschlangen-Funktion bereit, die notwendig ist, um die NSM- und LSM-Stubs 84, 86 und das LANSG-Modul 78 über das NPSUPPORT 40 mit ihren Peers auf dem Server 100 der A-Serie zu verbinden. Das QSP 76 arbeitet analog zu dem QSP 28 in einem herkömmlichen Netzwerk-Prozessor, wie oben beschrieben und in der 1 dargestellt ist. Spezifisch tauschen das QSP 76 und NPSUPPORT 40 Steuernachrichten aus, um Kommunikationskanäle zu initialisieren, einzurichten und zu beenden, zu konfigurieren und Fehler zu melden. Sie erstellen und analysieren ferner Kopfdatensätze, die am Anfang von Daten nachrichten platziert werden. Diese Kopfdatensätze spezifizieren die Nachrichten-Blockbildung, Nachrichtenlänge und Fern-Warteschlangen-Verweise (Remote Queue References, RQRs). Wie oben erwähnt ist, werden RQRs verwendet, um viele Punkt-zu-Punkt-Dialoge über die von dem LANSG-Modul verwalteten Leitungen im Multiplex-Verfahren zu senden. Entitäten auf dem Server 100 der A-Serie, die den von dem LANSG-Modul verwalteten Stationen entsprechen, werden einzelnen RQRs zugeordnet, wie die Stationen, denen sie entsprechen. Diese RQRs werden dann band-extern über die NSM/NSM-Stub- und LLM/LLM-Stub-Steuerdialoge ausgetauscht. Sobald die RQRs ausgetauscht worden sind, setzt der Erzeuger einer Nachricht die RQR der anderen Seite in den Kopfdatensatz ein, und somit kann der Empfänger diese Nachricht der entsprechenden Warteschlange zuordnen. Somit ermöglicht es das QSP 76, dass mehrere Dialoge über die physikalische Verbindung zwischen den Servern der A-Serie und den NT-Servern im Multiplex-Verfahren gesendet werden.
  • 4. LAN-Stationsgruppe (LANSG) 78
  • Wie das QSP 76, arbeitet die LANSG 78 analog zu der LANSG 26 in einem herkömmlichen Netzwerk-Prozessor, wie oben beschrieben und in der 1 dargestellt ist. Die LANSG 78 steuert die Initialisierung und Terminierung von Stationsgruppen auf bestimmten Leitungen, sowie die individuellen Stationen jeder Gruppe. Sie steuert ferner die Einstellung und das Abrufen von Attributen für diese Gruppen, das Melden von asynchronen Indikationen und das Weitergeben von Datennachrichten darauf. In dieser Ausführungsform kommuniziert die LANSG 78 mit dem QSP 76 über eine STRERMS-Schnittstelle. STREAMS ist eine auf UNIX-Systemen verbreitete Gerätetreiber-Schnittstelle mit Industriestandard, aber auch für Windows NT-Systeme erhältlich. In der vorliegenden Ausführungsform ist die STREAMS-Schnittstelle auf dem NT-Server 102 unter Verwendung des Produkts Mentat Portable Streams for Windows NT (MPS) implementiert, das bei Mentat, Inc., 1145 Gayley Ave. Suite 315, Los Angeles, CA 90024 USA, erhältlich ist.
  • Daten von dem NT-Server (z. B. über eine gemeinsam verwen dete NIC 50 von dem Netzwerk 15 empfangene Daten), die für einen Netzwerkprotokoll-Provider auf dem Server 100 der A-Serie bestimmt sind, werden an die LANSG 78 weitergegeben und dann durch das QSP 76, den Verbindung-Gerätetreiber (ICD) 70 und die physikalische Verbindung an das NPSUPPORT 40 auf dem Server 100 der A-Serie gesendet. In der vorliegenden Ausführungsform verwaltet das LANSG-Modul 78 physikalische Leitungen auf eine dem LANSG-Modul 26 eines herkömmlichen Unisys-Netzwerk-Prozessors ähnliche Art und Weise. In dieser Ausführungsform werden jedoch die Leitungen, die das LANSG-Modul 78 verwaltet, von in dem NT-Server 102 installierten Netzwerk-Schnittstellenkarten implementiert. Zum Beispiel definiert die gemeinsam verwendete NIC 50, die in dem NT-Server 102 installiert ist, eine von dem LANSG-Modul 78 verwaltete Leitung. Mehr als eine gemeinsam verwendete NIC 50 kann in dem NT-Server 102 installiert werden, wobei jede eine andere Leitung der Unisys-Netzwerk-Architektur definiert. Außerdem definiert, wie in der ebenfalls anhängigen Anmeldung mit der Serien-Nr.___ und dem Titel "A Virtual Lan Interface For High-Speed Communications Between Heterogeneous Computer Systems," (Anwalts-Akte: USYS-0038/TN086) beschrieben ist, eine simulierte lokale FDDI-Netzwerkumgebung innerhalb des Speicherbereichs des NT-Servers eine weitere Leitung innerhalb des LANSG-Moduls 78. Wie in der ebenfalls anhängigen Anmeldung beschrieben ist, stellt die simulierte FDDI-Netzwerkumgebung in Kombination mit der hierin beschriebenen Verbindung eine weitere Konnektivität-Lösung zwischen den TCP/IP-Netzwerkprotokoll-Providern 44, 58 auf jedem Server bereit. In der vorliegenden Ausführungsform wird die simulierte lokale FDDI-Netzwerkumgebung immer als die Leitung0 definiert.
  • Das LANSG-Modul 78 verwaltet eine Zuordnung von Leitungsnummern zu Adapter-Namen. Die Leitungsnummern werden durch auf dem Server 100 der A-Serie eingegebene Konfigurationsbefehle Stationsgruppen zugeordnet. Das LLM teilt diese Leitungsnummern dem LLM-Stub 86 mit. Die Adapter-Namen werden von Windows NT zugeordnet, während die NICs in dem NT-Server 102 konfiguriert und in der Windows NT-Registrierung gespeichert werden. Die LANSG 78 wird die Adapter-Namen von denjenigen NICs erhalten, die in der Registrierung an die LANSG 78 gebunden sind, und wird eine Zuordnung zu der dazugehörigen Leitungsnummer und andere Informationen verwalten. Die folgende Tabelle stellt die für jede verwendete Leitungsnummer verwalteten Informationen dar:
    Figure 00230001
  • 5. Lade/Verwerfe-Modul (Load/Dump Module, LDM) 82
  • Das LDM 82 stellt einen Mechanismus zum Simulieren eines Ladens einer Netzwerk-Prozessor-Firmware-Datei (eines Prozesses, der während der Initialisierung von herkömmlichen Netzwerk-Prozessoren ausgeführt wird) in die CNP-Plattform auf dem NT-Server 102 und zum Initiieren einer CNP-Zustandsentladung bereit. Das LDM befindet sich in einer ausführbaren Datei, CNP.EXE, die als ein NT-Dienst initiiert wird, wenn sich der NT-Server 102 bootet. Als Teil des simulierten Firmware-Ladevorgangs initiiert das LDM 82 den NSM-Stub-Prozess 84, der wiederum den LLM-Stub- Prozess 86 initiiert, und initiiert das QSP 76.6
  • 6. Netzwerkdienste-Modul-Stub (NSM-Stub) 84
  • Das NSM-Stub-Modul 84 ist ebenfalls Teil der ausführbaren Datei CNP.EXE und ist für das Ausführen von Befehlen/Antworten verantwortlich, die ihm von dem NSM 36 (einer Komponente des CNS 34) auf dem Server 100 der A-Serie gesendet wurden. Im Wesentlichen führt es die Funktionen des NSM-Stubs 30 eines typischen Unisys-Netzwerk-Prozessors aus. In der vorliegenden Ausführungsform ist das NSM-Stub 84 mit dem QSP-Modul 76 über eine STREAMS-Schnittstelle unter Verwendung von Standard-STREAMS-Aufrufen (d. h. open, close, ioctl, putmsg, getmsg) verbunden.
  • 7. Verbindungsebenen-Verwaltungs-Stub (Link Layer Manager Stub, LLM-Stub) 86
  • Das LLM-Stub-Modul 86, ebenfalls Teil der CNP.EXE, ist für das Ausführen von Befehlen/Antworten verantwortlich, die ihm von dem LLM 38 (einer Komponente des CNS 34) auf dem Server 100 der A-Serie gesendet wurden. Im Wesentlichen führt es die Funktionen des LLM-Stubs 32 eines typischen Unisys-Netzwerk-Prozessors aus. In der vorliegenden Ausführungsform ist das LLM-Stub 86 ebenfalls über eine STREAMS-Schnittstelle unter Verwendung von Standard-STREAMS-Aufrufen (d. h. open, close, ioctl, putmsg, getmsg) mit dem QSP-Modul 7b verbunden.
  • 8. Datensicherungsschicht-Attribut-Handler (Link Layer Attribute Handler, LLAH) 88
  • Das LLAH-Modul 88, ein weiteres Modul in der CNP.EXE, arbeitet ähnlich wie sein Gegenstück in einem herkömmlichen Unisys-Netzwerk-Prozessor. Im Speziellen ist das LLAH-Modul 88 für das Ausführen der detaillierten Verarbeitung verantwortlich, die mit Parsen, Validierung und Erstellen von Attribut-Listen zusammenhängt. Das LLAH setzt Validitätsregeln für Attributbereiche durch und prüft die Konsistenz zwischen Attributen. Das LLM-Stub 86 ist das einzige Modul, das mit dem LLAH verbunden ist.
  • B. Host-Schnittstellen-Funktion (Host Interface Function, HIF) – Alternative Ausführungsformen
  • Noch Bezug nehmend auf die 3, definieren der Verbindungs-Gerätetreiber 70, einschließlich seiner PCCA- und OPENCA-Treiber 72, 74 in der vorliegenden Ausführungsform, und die physikalische Verbindung, die von der Durchführungskarte 62, dem Kabel 64 und der EPCCA-Karte 66 gebildet wird, zusammen eine Host-Schnittstellen-Funktion (HIF). Gemäß einem weiteren Merkmal der vorliegenden Erfindung ist die Verfahrensschnittstelle zwischen dem QSP 76 und dem Verbindung-Gerätetreiber 70 der HIF so beschaffen, dass sie das QSP 76 von der HIF isoliert. Das ermöglicht es der vorliegenden Erfindung, mit unterschiedlichen Implementierungen der HIF verwendet zu werden. Im Speziellen wird die Verfahrensschnittstelle zwischen dem QSP 76 und dem Verbindung-Gerätetreiber 70 über einen Prozess etabliert, durch den jedes Modul Einsprungstellen (d. h. Zeiger) zu den Prozeduren, die seine Funktionalität implementieren, zusammen mit allen erforderlichen Variablen-Werten herausgibt. Eine weitere Gerätetreiber-Entität, die NNSDRLOG.SYS (nicht gezeigt) genannt wird, verwaltet eine Liste von diesen Einsprungstellen.
  • Der Verbindung-Gerätetreiber 70 der HIF registriert die folgenden Einsprungstellen und Attribute:
    HifSendBlockToHost() -- eine von dem QSP aufgerufene Funktion, um einen Datenblock an das MCP zu liefern;
    HifOpenUnit () -- eine von dem QSP aufgerufene Funktion, um einen von mehreren Kommunikationskanälen (Einheiten) zu initialisieren, über den von dem LANSG-Modul 78 empfangene Daten an die entsprechende Entität auf dem Server 100 der A-Serie übertragen werden können;
    HifCloseUnit() -- eine von dem QSP aufgerufene Funktion, um anzuzeigen, dass einer der Kommunikationskanäle (Einheiten) abgeschlossen wurde;
    maxQueuesSupported -- eine von der HIF initialisierte Variable, die das QSP referenzieren kann, um zu bestimmen, wie viele Kommunikationskanäle (Warteschlangen/Einheiten) es verwenden kann, um Nachrichten an das MCP 12 des Servers 100 der A-Serie zu senden; und
    platform -- eine von der HIF initialisierte Variable, die (über eine Aufzählung) eine bestimmte Implementierung der HIF kennzeichnet (zwei alternative HIF-Implementierungen sind unten beschrieben und in den 4 bzw. 5 dargestellt). In der vorliegenden Ausführungsform werden diese Funktionen und Variablen von dem OPENCA-Treiber 74 des Verbindung-Gerätetreibers 70 implementiert.
  • Ähnlich registriert das QSP 78 die folgenden Einsprungstellen:
    QspAckBlockToHost() -- eine von dem ICD aufgerufene Funktion, um dem QSP 78 anzuzeigen, dass ein bestimmter Nachrichtenblock erfolgreich an das MCP 12 geliefert wurde;
    QspReset() -- eine von dem ICD aufgerufene Funktion, um dem QSP 78 anzuzeigen, dass die Kommunikation mit dem MCP 12 über die Verbindung verloren gegangen ist und dass anstehende Nachrichten geleert werden sollen; und
    QspLRPut() -- eine von dem ICD aufgerufene Funktion, um einen Datenblock von dem Server der A-Serie an das QSP 78 zu liefern.
  • Um eine dieser Funktionen aufzurufen, wird ein Aufruf an die registrierte Einsprungstelle für diese Funktion durchgeführt. Als Folge dieser indirekten Adressierung können unterschiedliche Verbindung-Gerätetreiber für unterschiedliche Implementierungen der HIF auf eine Art und Weise installiert werden, die für das QSP 76 vollkommen transparent ist.
  • Die 4 und 5 stellen zwei alternative Ausführungsformen der HIF dar, welche die Modularität darstellen, die von der Ausgestaltung der oben beschriebenen Verfahrensschnittstelle bereitgestellt wird. In der 4 wird die physikalische Verbindung (d. h. die Durchführungskarte 62, das Kabel 64 und die EPCCA-Karte 66) gegen eine PCI Bridge-Karte 67 ausgetauscht, die über ein Kabel 65 direkt mit einem Anschluss an einer der CMUs 18b des EAM 14 des Servers 100 der A-Serie verbindet. Durch das direkte Verbinden mit der CMU wird ein Teil der inhärenten Wartezeit in dem CS-Bus II-Protokoll vermieden. Das sorgt. für eine direktere, schnellere Verbindung zwischen den E/A-Teilsystemen der zwei Server 100, 102. Weil die physikalische Verbindung verändert wird, wird ein modifizierter Verbindung-Gerätetreiber 70' bereitgestellt. Der modifizierte Verbindung-Gerätetreiber 70' umfasst ein einzelnes Gerätetreiber-Modul PXN 73, das die Schnittstelle zwischen dem QSP 76 und der Hardware auf der PCI Bridge-Karte 67 bereitstellt. Die Verfahrensschnittstelle und der Mechanismus, über den das QSP 76 und der Verbindung-Gerätetreiber 70' Einsprungstellen für die jeweiligen Prozeduren dieser Schnittstelle registrieren, bleiben jedoch unverändert. Dementsprechend sind die Veränderungen an der HIF für das QSP 76 und die anderen Module der vorliegenden Erfindung transparent, welche die kooperative Netzwerk-Plattform (Cooperative Networking Platform, CNP) umfassen.
  • Die 5 ist eine Ausführungsform, in der das System der A-Serie über eine Software in dem NT-Server 102 emuliert wird. Unisys stellt ein derartiges emuliertes System in seinen Unternehmen-Servern der Serie ClearPath HMP NX 4200 bereit. In dieser Ausführungsform wird die physikalische Verbindung derart emuliert, dass sie zu einer Speicher-zu-Speicher-Verbindung 63 zwischen dem Speicherbereich des emulierten E/A-Teilsystems 14' und dem Speicherbereich des NT-Systems wird. Die emulierte Verbindung 63 arbeitet auf eine ähnliche Art und Weise wie die Durchführungskarte 62-, Kabel 64-, EPCCA-Karte 66- und PCCA 72-Komponenten der Hardware-Implementierung in 3. Der Verbindung-Gerätetreiber 70'' in dieser Ausführungsform umfasst eine modifizierte Form 74' des OPENCA-Moduls 74 der Implementierung in 3. Wieder wird jedoch die Verfahrensschnittstelle zwischen dem modifizierten OPENCA-Modul 74' und dem QSP 76 nicht verändert, so dass der emulierte Server der A-Serie und dessen emulierte Verbindung 63 mit dem NT-Server für das QSP 76 und die anderen Module der vorliegenden Erfindung transparent sind, welche die kooperative Netzwerk-Plattform (CNP) umfassen.
  • C. Arbeitsweise
  • Die 6A–6F liefern weitere Details darüber, wie Daten zwischen dem Server 100 der A-Serie und dem NT-Server 102 über den Verbindung-Gerätetreiber der HIF und das QSP-Modul 76 übertragen werden. Die in den 6A–6E gelieferten Details sind auf alle der in den 3, 4 und 5 gezeigten drei Ausführungsformen der HIF anwendbar. Wie in der folgenden Abhandlung verwendet, bezieht sich der Begriff Verbindung-Gerätetreiber (ICD) somit auf eine beliebige der drei Ausführungsformen des oben beschriebenen Verbindung-Gerätetreibers.
  • Das QSP 76 sendet im Multiplex-Verfahren mehrere Client-Dialoge (z. B. Dialoge mit den NSM-Stub- und LLM-Stub-Modulen 84, 86 und mit den von der LANSG 78 definierten unterschiedlichen Stationen) über eine oder mehrere Übertragungseinheiten. Einheiten stellen eine Abstraktion der von dem Verbindung-Gerätetreiber (ICD) unterstützten Kommunikationspfade dar. Einheiten können logische Dialoge oder physikalische Geräte sein. Um die Einheitsressourcen in vollerem Umfang zu nutzen, kann das QSP 76 Nachrichten, die auf eine Übertragung über eine gleiche Einheit warten, zu einem Block anhäufen, der in einem einzigen Arbeitsgang übertragen werden kann. Das QSP 76 unterstützt eine derartige Blockbildung durch das Bereitstellen eines Nachrichten-Zählerfeldes in seinen Nachrichten-Kopfdatensätzen. Der erste Nachrichten-Kopfdatensatz in einem Block enthält die Anzahl der Nachrichten, die der Block in seinem Nachrichten-Zählerfeld enthält. Nachfolgende Nachrichten-Kopfdatensätze innerhalb des Blocks besitzen in diesem Feld einen Wert Null.
  • Der ICD nimmt dann jeden Block und programmiert die physikalische Verbindung (d. h. die EPCCA-Karte 66, die PCI Bridge-Karte 67 oder die emulierte Speicher-zu-Speicher-Verbindung 63, abhängig von der Implementierung), um den Block auf den Server der A-Serie zu übertragen. In der umgekehrten Richtung wird der ICD, wenn eine Nachricht über die physikalische Verbindung in den Speicher des NT-Servers 102 übertragen wird, entweder von einer Unterbrechung (in dem Fall der Hardware-Verbindungen in 3 und 4) oder von einem Funktionsaufruf (in dem Fall der emulierten Verbindung 63 in 5) erweckt. Der ICD liefert die empfangene Nachricht an das QSP 76, das sie wiederum dem entsprechenden Client-Dialog (z. B. dem NSM-Stub 84, LLM-Stub 86 oder einer bestimmten Station, die von der LANSG 78 bestimmt wird), basierend auf der zu der Nachricht gehörigen RQR, zuteilt.
  • Die 6A–6D liefern weitere Informationen bezüglich der Schritte, die von dem QSP 76 und dem ICD bei der Übertragung von Nachrichten von einem Client auf dem NT-Server 102 (z. B. dem NSM-Stub 84, LLM-Stub 86 oder einer von der LANSG 78 definierten Station) an den Server 100 der A-Serie über die physikalische Verbindung ausgeführt werden. Dieser Übertragungsprozess startet, wenn ein Client, zum Beispiel das LANSG-Modul 78, der von dem NIC 50 empfangene Daten an den Server 100 der A-Serie weitergeben soll, das QSP 76 aufruft, welches anfordert, dass eine Nachricht (z. B. die aus dem Netzwerk empfangenen Daten) an den Server 100 der A-Serie übertragen werden soll. Mit der Anforderung wird ein Parameter übergeben, der auf nicht zusammenhängende Nachrichtensegmente zeigt, welche die gesamte Nachricht umfassen. In dem Schritt 112 bestimmt das QSP 76, auf welcher Einheit die Nachricht übertragen werden soll. Als Nächstes berechnet in dem Schritt 114 das QSP 76 die Gesamtgröße der Nachricht durch Prüfen jedes nicht zusammenhängenden Segments in der Nachricht. In dem Schritt 116 wird ein Kopfdatensatz an den Anfang der Nachricht angefügt und eine Deskriptorliste gebildet, die auf den Kopfdatensatz und auf jedes Segment in der Nachricht zeigt. Als Nächstes bestimmt in dem Schritt 118 das QSP 76, ob die Blockbildung (oben beschrieben) für diese Einheit unterstützt wird. Wenn ja, bestimmt in dem Schritt 120 das QSP 76, ob irgendwelche Blöcke gegenwärtig auf eine Übertragung warten. Wenn ja, bestimmt in dem Schritt 121 das QSP 76, ob die Nachricht in den letzten anstehenden Block passt. Wenn ja, dann fügt in dem Schritt 122 das QSP 76 die Deskriptorliste zu dem letzten anstehenden Block hinzu. Die Steuerung schreitet dann zu dem Schritt 127 (6B).
  • Wenn in dem Schritt 118 die Blockbildung für diese Einheit nicht unterstützt wird, oder wenn in dem Schritt 120 bestimmt wird, dass gegenwärtig keine Blöcke auf eine Übertragung warten, oder wenn in dem Schritt 121 bestimmt wird, dass die Nachricht nicht in den letzten anstehenden Block passt, dann schreitet die Steuerung in allen drei Fällen zu dem Schritt 124. In dem Schritt 124 erstellt das QSP 76 einen Block, der nur die in dem Schritt 116 gebildete Deskriptorliste enthält. Als Nächstes wird in dem Schritt 126 der neu erzeugte Block der Liste der anstehenden Blöcke hinzugefügt. Die Steuerung schreitet dann zu dem Schritt 127 (6B).
  • Mit Bezug auf die 6B bestimmt in dem Schritt 127 das QSP 76, ob irgendwelche Blöcke anstehen. Wenn nicht, kehrt das QSP 76 einfach zu dem Client zurück. Wenn es jedoch anstehende Blöcke gibt, die übertragen werden sollen, schreitet die Steuerung zu dem Schritt 128.
  • In dem Schritt 128 versucht das QSP 76, den ersten Block in der Liste der anstehenden Blöcke durch Aufrufen der HifSend BlockToHost()-Prozedur des ICD an den ICD zu senden. Wie durch den mit "A" gekennzeichneten Pfeil angezeigt wird, beginnt der ICD die Verarbeitung der Anforderung an diesem Punkt. Die von dem ICD ausgeführten Schritte sind in der 6C dargestellt. Noch Bezug nehmend auf die 6B, geht jedoch die Verarbeitung des QSP weiter zu dem Schritt 130, worin das QSP 76 bestimmt, ob der ICD den Block für die Übertragung akzeptiert hat. Wenn ja, wird dieser Block aus der Liste anstehender Blöcke in dem Schritt 132 entfernt, und die Steuerung kehrt zu dem Schritt 127 zurück, worin das QSP 76 wieder prüft, ob es irgendwelche anstehenden Blöcke zu übertragen gibt, und die Verarbeitung setzt sich für alle derartigen nachfolgenden Blöcke fort. Wenn jedoch in dem Schritt 130 bestimmt wird, dass der ICD einen bestimmten Block für die Übertragung nicht akzeptiert hat, dann kehrt das QSP 76 zu dem Client zurück, wobei es den die zu sendende Nachricht enthaltenden Block auf der Liste anstehender Blöcke lässt.
  • Bezug nehmend auf die 6C beginnt nun der ICD die Verarbeitung der HifSendBlockToHost()-Anforderung von dem QSP in dem Schritt 134, worin er bestimmt, ob sich die physikalische Verbindung in dem Fluss-Steuerungs-Modus befindet. Der Fluss-Steuerungs-Modus ist ein Modus, in dem das MCP-Betriebssystem des Servers 100 der A-Serie nicht für Daten auf der spezifischen Einheit empfangsbereit ist, zum Beispiel, weil kein Puffer verfügbar ist. Wenn sich die physikalische Verbindung in dem Fluss-Steuerungs-Modus befindet, sendet der ICD einen Wert "FALSE" an das QSP 76 zurück und beendet die Verarbeitung der Übertragung an diesem Punkt. Wenn sich die physikalische Verbindung nicht in dem Fluss-Steuerungs-Modus befindet, dann schreitet die Steuerung zu dem Schritt 136, worin der ICD bestimmt, ob die physikalische Verbindung eine Raffungs-Funktion unterstützt. Die Raffung ist die Fähigkeit, Daten von nicht zusammenhängenden Speicherbereichen in einem Arbeitsgang zu übertragen. Wenn die physikalische Verbindung keine Raffungs-Fähigkeit unterstützt, schreitet die Steuerung zu dem Schritt 138, worin der ICD die Daten, auf die von der Deskriptorliste (von dem QSP 76 an ihn weitergegeben) gezeigt wird, in einen zusammenhängenden Puffer kopiert. Als Nächstes erstellt in dem Schritt 140 der ICD eine Pseudo-Deskriptorliste, die auf den einzigen, zusammenhängenden Puffer zeigt. Die Steuerung schreitet dann zu dem Schritt 142.
  • In dem Schritt 142, der entweder direkt aus dem Schritt 136 (Raffung unterstützt) oder aus dem Schritt 140 (Raffung nicht unterstützt) erreicht wurde, programmiert der ICD die physikalische Verbindung (d. h. die EPCCA-Karte 66, die PCI Bridge-Karte 67 oder die emulierte Speicher-zu-Speicher-Verbindung 63, abhängig von der jeweiligen Ausführungsform), um die Daten zu übertragen, auf die entweder von der von dem QSP 76 (Raffung) empfangenen Deskriptorliste oder von der in dem Schritt 140 (keine Raffung) erzeugten Pseudo-Deskriptorliste gezeigt wird. Der ICD sendet dann einen Wert "TRUE" an das QSP 76 zurück.
  • Die 6D stellt die Schritte dar, die von dem ICD und QSP 76 ausgeführt werden, wenn die Übertragung erfolgt ist. Wie dargestellt ist, wird, wenn die Übertragung erfolgt ist, der ICD erweckt. In dem Schritt 144 empfängt der ICD eine Meldung darüber, ob die Übertragung erfolgreich abgeschlossen wurde. Wenn nicht, schreitet die Steuerung zu dem Schritt 146, worin der ICD versucht, den Fehler zum Beispiel durch Zurückübertragen des fraglichen Blocks, Zurücksetzen der physikalischen Verbindung usw. zu beheben. Wenn die Übertragung erfolgreich abgeschlossen wurde, schreitet die Steuerung zu dem Schritt 148. In dem Schritt 148 stellt der ICD den Fluss-Steuerungs-Zustand der physikalischen Verbindung ein. Das geschieht, weil in den oben beschriebenen Ausführungsformen der physikalischen Verbindung die Verbindung regelmäßig abgefragt wird. Wenn die Übertragung erfolgt ist, ist die Verbindung möglicherweise nicht in der Lage, eine weitere Übertragung einzuleiten, bis sie wieder abgefragt wird; deshalb wird der Fluss-Steuerungs-Zustand eingestellt, um dies zu reflektieren. Als Nächstes ruft in dem Schritt 150 der ICD die QspAckBlockToHost()-Prozedur auf, um das QSP zu benachrichtigen, dass die Übertragung abgeschlossen ist, und um anzuzeigen, welche Deskriptorliste übertragen wurde. In dem Schritt 152 führt der ICD eine Säuberungs-Prozedur aus und kehrt dann zurück.
  • Wie an dem Punkt "B" gezeigt ist, geht das QSP 76, wenn es die QspAckBlockToHost()-Meldung von dem ICD empfängt, die es benachrichtigt, dass die Übertragung erfolgreich abgeschlossen ist, zu Schritt 154, worin sämtliche Nachrichten in dem übertragenen Block freigegeben werden, was veranlasst, dass die Clients, die sie gesendet haben, darüber benachrichtigt werden, dass sie erfolgreich übertragen wurden. In dem Schritt 156 werden die Blockstrukturen, einschließlich der Nachrichten-Kennsätze und der Deskriptorliste, recycelt und für anschließende Übertragungen verfügbar gemacht. Die Steuerung kehrt dann zur Verarbeitung von anschließenden Blöcken zu dem Schritt 127 in 6B zurück.
  • Die 6E–6F stellen die von dem ICD und QSP 76 bei der Übertragung einer Nachricht von dem Server 100 der A-Serie an den NT-Server 102 ausgeführten Schritte dar. Wie gezeigt ist, macht der ICD vor dem Empfangen von irgendwelchen Nachrichten von dem Server der A-Serie über die physikalische Verbindung leere Empfangs-Puffer für die Verbindung verfügbar. Wenn eine Nachricht von dem Server 100 der A-Serie an den NT-Server über die physikalische Verbindung (z. B. über die Durchführungskarte 62, über das Kabel 64 und über die EPCCA-Karte 66 in der Ausführungsform in 3) übertragen wird, wird der ICD mit einer Meldung erweckt, dass eine Nachricht in einem der leeren Empfangs-Puffer empfangen wurde, die er aufgegeben hat. In dem Schritt 158 gibt der ICD die Nachricht an das QSP 76 unter Verwendung der QspLRPut()-Funktion weiter und kehrt zurück.
  • In dem Schritt 160 bestimmt das QSP 76, ob die Nachricht eine Steuernachricht ist. Wenn ja, verarbeitet in dem Schritt 164 das QSP 76 die Steuernachricht lokal und gibt dann die Nachricht in dem Schritt 166 frei und kehrt zurück. Wenn die Nachricht keine Steuernachricht ist, dann schreitet die Steuerung zu dem Schritt 162. In dem Schritt 162 bestimmt das QSP 76 aus der. RQR in dem Nachrichten-Kopfdatensatz, welche Station die Nachricht empfangen soll. Als Nächstes wird in dem Schritt 168 die Nachricht an die entsprechende Station weitergegeben.
  • Bezug nehmend auf die 6F, wird, wenn das QSP 76 oder einer von dessen Clients den Nachrichten-Puffer freigibt, eine Nachrichten-Freigabe-Rückruf-Funktion des ICD aufgerufen. In dem Schritt 170 fügt der ICD den freigegebenen Puffer der Liste von verfügbaren Puffern hinzu, welche die physikalische Verbindung dann verwenden kann, um nachfolgende Nachrichten in der oben beschriebenen Art und Weise zu empfangen.
  • II. DER ROUTER 80
  • Für Darstellungszwecke wieder Bezug nehmend auf die 3, routet, wie oben erwähnt ist, der Router 80 Daten zwischen einem ersten Netzwerkprotokoll-Provider (z. B. BNAv2 HRNP 42 oder TCP/IP HRNP 44) auf einem ersten Computersystem (über die Verbindung), einem zweiten Netzwerkprotokoll-Provider (z. B. TCPIP.SYS 58) auf einem zweiten Computersystem und einer NIC 50 auf dem zweiten Computersystem, so dass die NIC 50 von beiden Netzwerkprotokoll-Providern gemeinsam verwendet werden kann.
  • Die 7 stellt die verschiedenen Datenpfade dar, die der Router 80 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung bereitstellt. Wenn von der NIC 50 Daten aus dem Netzwerk 15 empfangen werden, routet der Router 80 die Daten an den ersten Netzwerkprotokoll-Provider (z. B. TCP/IP HRNP 44 oder BNAv2 HRNP 42) über die Verbindung, wenn eine mit den Daten empfangene Netzwerkadresse mit der ersten Netzwerkadresse übereinstimmt, wie von dem Pfad 174 dargestellt ist. Wenn die empfangenen Daten eine Adresse besitzen, die mit der des zweiten Netzwerkprotokoll-Providers (z. B. TCPIP.SYS 58) übereinstimmt, werden die Daten zu diesem Netzwerkprotokoll-Provider geroutet, wie von dem Pfad 172 dargestellt ist. Die aus dem Netzwerk 15 mit einer Broadcast-Adresse empfangenen Daten werden über die Pfade 172 und 174 sowohl an den ersten (über die Verbindung) als auch an den zweiten Netzwerkprotokoll-Provider geroutet. Ausgehende Daten werden von jedem Netzwerkprotokoll-Provider über die jeweiligen Pfade 172, 174 zu der NIC 50 geroutet. Wenn jedoch von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider ausgehende Daten an den anderen Netzwerkprotokoll-Provider adressiert sind, ermöglicht es eine "Prüfschleifen"-Fähigkeit dem Router 80, diese Daten direkt von einem Netzwerkprotokoll-Provider an den anderen zu routen, wobei er die NIC 50 umgeht, wie durch den Pfad 176 dargestellt ist. Ferner werden von entweder dem ersten oder dem zweiten Netzwerkprotokoll-Provider ausgehende Daten, die eine Broadcast-Adresse besitzen, über den jeweiligen Pfad 172 oder 174 an die gemeinsam verwendete NIC 50 und ferner über den "Prüfschleifen"-Pfad 176 an den anderen Netzwerkprotokoll-Provider geroutet, wobei die NIC 50 umgangen wird. In der vorliegenden Ausführungsform wird der "Prüfschleifen"-Pfad 176 nur für TCP/IP-zu-TCP/IP-Übertragungen implementiert.
  • Wie ferner in den 3 und 7 dargestellt ist, ist die vorliegende Erfindung auf die Verwendung mit nur einem Netzwerkprotokoll-Provider auf jedem System nicht beschränkt. Vielmehr kann die vorliegende Erfindung verwendet werden, um Daten an und von mehreren Netzwerkprotokoll-Providern auf jedem System zu routen, wobei jeder Netzwerkprotokoll-Provider dessen eigene Netzwerkadresse besitzt. Außerdem können in der vorliegenden Ausführungsform die Netzwerkprotokoll-Provider auf dem Server 100 der A-Serie sowohl die TCP/IP-Netzwerkprotokoll-Provider (z. B. das TCP/IP-HRNP 44) als auch die BNAv2-Netzwerkprotokoll-Provider (z. B. das BNAv2-HRNP 42) einschließen. In dieser Ausführungsform unterscheidet der Router 80 zwischen BNAv2-Rahmen und TCP/IP-Rahmen gemäß dem in dem herkömmlich übertragenen US-Patent Nr. 5,379,296, mit dem Titel "Verfahren und Gerät zum Verbinden einer Arbeitsstation mit einer Vielzahl von Computer-Plattformen" (Johnson et al.) beschriebenen Verfahren, das hierdurch unter Bezugnahme in dessen Gesamtheit eingeschlossen wird.
  • Die 8 ist ein Blockdiagramm, das weitere Details der Implementierung des Routers 80 gemäß der bevorzugten Ausführungsform darstellt. In dieser Ausführungsform sind beide LANSG 78, QSP 76 als Kernel-Ebene-Gerätetreiber innerhalb des Kernelbereichs des NT-Betriebssystems implementiert. Die Schnittstelle zwischen dem LANSG 78 und QSP 76 ist eine STREAMS-Schnittstelle, die unter Verwendung des Mentat-Portable-Streams (MPS) für die Laufzeit-Umgebung des Windows NT implementiert ist. In dieser Ausführungsform ist die Funktionalität des Routers 80 in zwei Komponenten implementiert, einer Transport-Treiber-Komponente (JTD) 182 und einer NIC-Treiber-Komponente (JND) 184. Die JND-Komponente 184 ist in Form eines NDIS-Miniport-NIC-Treibers implementiert, der hierin als JANUS.SYS bezeichnet wird. "Janus" stellt einen Verweis aus der römischen Mythologie auf den antiken Gott der Tore und Türen dar, der mit zwei in entgegengerichtete Richtungen sehenden Gesichtern abgebildet wird. Die JTD-Komponente ist als ein Modul (JTD.C) implementiert, das von dem LANSG.C-Modul (das die LANSG-Funktionalität enthält) separat kompiliert wird, aber als Teil des LANSG.SYS verknüpft.
  • Die JTD-Komponente 182 des Routers 80 erhält eine Adapter-Tabelle mit dem Zustand jedes NIC aufrecht, für das sie verantwortlich ist, einschließlich der IP-Adressen der Netzwerkprotokoll-Provider auf den Servern 100 der A-Serie und NT-Servern 102, an die sie einkommende Daten gemäß der vorliegenden Erfindung routen müsste. Das Folgende ist eine Strukturdefinition der Adapter-Tabelle in der C-Sprache:
    Figure 00350001
    Figure 00360001
  • Das Feld "Adapter Name" der Struktur enthält den dem bestimmten gemeinsam verwendeten NIC (z. B. das NIC 50) zugewiesenen Adapter-Namen, der die Eingabe repräsentiert. Die Felder "Jtd Adapter Handle" und "Medium" enthalten Werte, die von der NdisOpenAdapter-Funktion der NDIS-Spezifikation zurückgesendet werden. Die Felder "Packet_Pool_Handle" und "Buffer_Pool_Handle" enthalten Werte, die von den NdisAllocatePacketPool- und Ndis AllocateBufferPool-Funktionen der NDIS-Spezifikation zurückgesendet werden. Das Feld "Jnd_Adapter_Handle" enthält einen Wert, der von der JND-Komponente 184 erhalten wird. Dieser Wert repräsentiert das einzigartige Handle, das von dem JND verwendet wird, um den Adapter zu identifizieren. Das Feld "Mcp_Ip_Adr" enthält die IP-Adresse des Netzwerkprotokoll-Providers (z. B. des TCP/IP-HRNP 44) auf dem Server der A-Serie, der dieses bestimmte NIC gemeinsam verwendet, und das Feld "Nt_Ip_Adr" enthält die IP-Adresse des Netzwerkprotokoll-Providers (z. B. des TCPIP.SYS 58) auf dem NT-Server 102, der dieses NIC gemeinsam verwendet. Alternativ können andere Ausführungsformen mehrere IP-Adressen auf einer einzigen Adapterleitung für einen gegebenen Netzwerkprotokoll-Provider unterstützen.
  • Auch wenn das JTD.C mit dem LANSG.C in das LANSG.SYS verknüpft ist und diese Info in der Stationsgruppen-Tabelle des LANSG speichern könnte, wird eine separate (aber verknüpfte) Adapter-Tabelle in dieser Ausgestaltung gewählt, um die NDIS-Schnittstelle in dem JTD.C zu isolieren, und um die Größe der Stationsgruppen-Tabelle (eine "Maske" in der Größe der Stationsgruppen-Tabelle wird in der Schnittstelle von dem LLM-Stub und LRNSG.C zum Setzen der Stationsgruppen-Attribute verwendet) zu minimieren. Die Adapter-Tabelle ist mit der Stationsgruppen-Tabelle des LANSG 78 über die folgende zusätzliche Eingabe in der Stationsgruppen-Tabelle verknüpft, die zu einer gegebenen Eingabe der Adapter-Tabelle zeigt:
    Figure 00370001
  • Die JTD-Komponente 182 erhält die IP-Adressen der TCP/IP-Netzwerkprotokoll-Provider auf jedem Server 100, 102, an die sie einkommende Daten routen müsste, wie folgt. Wenn das TCPIP.SYS 58 konfiguriert ist, um eine IP-Adresse auf einem bestimmten NIC (z. B. das NIC 50) zu verwenden, speichert sie auf dem NT-Server 102 eine Eingabe, die diese IP-Adresse enthält, in dem Windows NT-Register an der folgenden Stelle:
    HKEY_LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\<AdapterName>\Parameters\TCPIP.
  • Die JTD-Komponente 182 besitzt einen Zugriff auf diese Stelle in dem Register für sämtliche NICs, die konfiguriert sind, um "gemeinsam verwendet" zu werden, und speichert die aus dem Register bezogenen IP-Adressen für jedes gemeinsam verwendete NIC in dessen lokalen Tabellen.
  • Auf dem Server 100 der A-Serie werden die IP-Adressen unter Verwendung des Befehls NW-TCPIP-TCPIPID konfiguriert. Dieser Befehl veranlasst das TCP/IP-HRNP auf dem Server 100 der A-Serie, dass es eine einzige IP-Adresse mit einem Netzwerk-Prozessor und einer Leitung auf diesem Netzwerk-Prozessor verknüpft. Wie oben erwähnt ist, simuliert in der vorliegenden Ausführungsform die Verbindung einen herkömmlichen Netzwerk-Prozessor aus der Sicht eines Servers der A-Serie. Die Leitung0 ist für das simulierte FDDI-Netzwerk reserviert, das in der zuvor genannten mitschwebenden Anmeldung mit der Serien-Nr. ___,mit dem Titel "Eine virtuelle LAN-Schnittstelle für Hochgeschwindigkeits-Kommunikationen zwischen heterogenen Computersystemen" (Anwalts-Akte: USYS-0038/TN086) beschrieben ist. Leitungsnummern oberhalb der Leitung0 können für NICs verwendet werden, die gemäß der vorliegenden Erfindung gemeinsam zu verwenden sind. Das LANSG ordnet bestimmten Adaptern Leitungsnummern zu, wie zuvor beschrieben wurde. Wenn das TCP/IP-HRNP 44 mit einer bestimmten IP-Adresse konfiguriert wird, sendet es die konfigurierte IP-Adresse an das LLM-Stub 86 unter Verwendung eines Befehls Setze-Stations-Schnittstelle (SSI) zusammen mit anderen verschiedenartigen Daten. Das LANSG 78 empfängt den SSI-Befehl von dem LLM-Stub 86 und gibt die IP-Adresse an die JTD-Komponente 182 des Routers 80 für die Aufnahme in dessen Tabellen weiter.
  • Das LANSG 78 erhält ferner eine Zuordnung der mit einem bestimmten gemeinsam verwendeten NIC assoziierten IP-Adressen in dessen Tabellen aufrecht. Die folgende Tabelle stellt die für diese Zuordnung aufrechterhaltene Information dar:
    Figure 00380001
  • Wie gezeigt ist, wird für jedes gemeinsam verwendete NIC (identifiziert durch dessen Adapter-Handle) eine Zuordnung für sowohl die IP-Adresse des Netzwerkprotokoll-Providers auf dem Server 100 der A-Serie, der dieses bestimmte NIC gemeinsam verwendet, als auch für die IP-Adresse des Netzwerkprotokoll-Providers auf dem NT-Server aufrechterhalten, der dieses NIC gemeinsam verwendet.
  • Die NIC 50 und dessen Gerätetreiber (<nicdrv>.sys) 54 sind in der normalen Art und Weise gemäß den von dem NIC-Verkäufer gelieferten Anweisungen installiert. Die Einfassungen in Windows NT für das NIC 50 (sowie für ein beliebiges anderes gemeinsam verwendetes NIC) müssen jedoch aus ihren Originaleinstellungen verändert werden, wenn das NIC und dessen Treiber installiert werden. Spezifisch müssen die Janus-NIC-Treiber-(JND)- und die Janus-Transport-Treiber-(JTD)-Komponenten des Routers 80 in die Einfassungen eingefügt werden. Alle NT-Transport-Treiber (z. B. das TCPIP.SYS) müssen mit "Adaptern" in dem JND rückverknüpft werden. Zusätzlich muss das JTD als ein Transport-Treiber mit dem NIC-Treiber 54 verknüpfen. Weil das JTD als ein Modul implementiert ist, das in das LANSG.SYS verknüpft ist, ist das LANSG.SYS tatsächlich als der Transport-Treiber installiert.
  • Zusätzlich zu dem Vorangegangenen ist die folgende neue Eingabe in dem Windows NT-Register erforderlich – EnableIP RoutingInMCP. Diese Registereingabe wird von der JTD-Komponente verwendet, um das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie als ein IP-Router für Rahmen mit "unbekannter" IP-Adresse zu kennzeichnen, und um die Beziehung des IP-Routers auf dem Server 100 der A-Serie zu dem IP-Router auf dem NT-Server 102 (falls aktiviert) zu kennzeichnen. Das EnableIPRoutingInMCP (Ermögliche IP Routing ImMCP) kann 3 mögliche Werte besitzen: "Primär", "Sekundär" und "Inaktiv". Wenn auf "Primär" gesetzt wird, routet das JTD etwaige einkommende IP- oder ARP-Rahmen mit unbekannten IP-Adressen immer an das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie über die Verbindung. Wenn das EnableIPRoutingInMCP auf "Sekundär" gesetzt wird, dann routet das JTD etwaige einkommende IP- oder ARP-Rahmen mit unbekannten IP-Adressen nur an das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie, wenn das EnanbleIPRouting (eine existierende NT-Register-Eingabe) nicht gesetzt ist. Wenn das EnanbleIPRouting gesetzt ist, dann geht es vor, und IP- oder ARP-Rahmen mit unbekannten IP-Adressen werden an das TCPIP.SYS 58 auf dem NT-Server 102 gesendet. Wenn das EnableIPRoutingInMCP auf "Inaktiv" gesetzt wird, dann routet das JTD etwaige einkommende IP- oder ARP-Rahmen mit unbekannten IP-Adressen nicht an das TCP/IP-HRNP 44, sondern sendet derartige Rahmen vielmehr an das TCPIP.SYS 58.
  • Auf dem Server der A-Serie wurden an der CNS-Software 34 Veränderungen vorgenommen. Zunächst wurden zwei neue Attribute für Verbindungsgruppen vom LAN-Typ wie folgt definiert:
    • 1. ADAPTERNAME – Das ist ein setzbares/beziehbares Attribut, das vom Typ "String" ist, mit einer maximalen Länge von 17 Zeichen. Dieses Attribut wird verwendet, um eine gegebene Verbindungsgruppe, die innerhalb des CNS 34 definiert ist, dem bestimmten gemeinsam verwendeten NIC (z. B. das NIC 50) zuzuordnen, die es repräsentiert.
    • 2. ADAPTERTYPE – Das ist ein setzbares/beziehbares Attribut, das den Adapter-Typ identifiziert, auf den sich das Attribut ADAPTERNAME bezieht. In der vorliegenden Ausführungsform kann das Attribut ADAPTERTYPE auf VLAN (bezugnehmend auf das simulierte FDDI-Netzwerk, das in der zuvor erwähnten mitschwebenden Anmeldung beschrieben ist) oder auf FASTETHERNET (bezugnehmend auf die in dieser Ausführungsform unterstützten NIC-Typen) gesetzt werden.
  • Auf einem gemeinsam verwendeten NIC ist der Router 80 sowohl dem NT-TCPIP.SYS 58 als auch dem TCP/IP-HRNP 44 auf dem Server 100 der A-Serie transparent. Das NT-TCPIP.SYS ist mit dem Router 80 verbunden, wie es normalerweise mit einem NIC-Treiber über die NDIS-Schnittstelle verbunden wäre. Das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie ist ferner mit dem Router 80 verbunden, wie es normalerweise mit einer Netzwerkschnittstelle über das LANSG 78 verbunden wäre. Weder das NT-TCPIP.SYS 58 noch das TCP/IP-HRNP 44 der A-Serie sind sich dessen bewusst, dass sie das gleiche NIC gemeinsam verwenden. Zusätzlich ist der NIC-Treiber 54 mit dem Router 80 verbunden, wie es normalerweise mit einem NDIS-Protokoll-Treiber verbunden wäre, wie dem NT-TCPIP.SYS.
  • Die 9A–9C liefern weitere Details der eingebundenen Routung-Funktionalität des Routers 80 gemäß einer Ausführungsform davon, und stellen ferner eine Ausführungsform eines Verfahrens der vorliegenden Erfindung dar. Die in den 9A–9C dargestellte Ausführungsform unterstützt den oben beschriebenen "Rückschleife"-Pfad jedoch nicht. Die Funktionalität wird in einer Pseudocode-Form präsentiert.
  • Bezugnehmend auf die 9A bestimmt in der Zeile 200 der Router 80 aus dem Längenfeld des MAC-Kopfdatensatzes eines von dem Netzwerk empfangenen Daten-Rahmen, ob die Länge des Rahmens kleiner als oder gleich 1500 Bytes ist, in welchem Fall davon ausgegangen wird, dass der Rahmen ein 802.3-Rahmen ist, der einen 802.3-MAC-Kopfdatensatz, einen 802.2-LLC-Kopfdatensatz und einen 802.1a-SNAP-(Teilnetzwerk-Verbindungspunkt)-Kopfdatensatz enthält. Wenn das der Fall ist, dann bestimmt in der Zeile 202 der Router 80 aus dem DSAP-Feld des LLC-Kopfdatensatzes des Rahmens, ob der Rahmen ein SNAP-Rahmen ist. Wenn ja, dann bestimmt in der Zeile 204 der Router 80 aus dem Steuerfeld des LLC-Kopfdatensatzes, ob der Rahmen ferner ein Rahmen des Typs unbezifferte Information (UI) ist (d. h. ein Rahmen-Typ, der für "Informations"-(Daten)-Rahmen in dem 802.2-LLC-Protokoll verwendet wird). Wenn der Rahmen kein UI-Rahmen ist, dann wird er identifiziert als besäße er einen Typ UNKNOWN (Unbekannt), und ein entsprechender Wert wird in einer Variable type_of_frame_rcvd (Typ des empfangenen Rahmens) in der Zeile 208 gespeichert, um den UNKNOWN-Typ anzuzeigen. Wenn in der Zeile 204 der Rahmen als ein UI-Rahmen bestimmt wird, dann bestimmt in den Zeilen 206 der Router 80 weiter, ob der Rahmen ein IP-Rahmen, ein ARP-Rahmen oder ein UNKNOWN-Typ ist, und speichert den identifizierten Typ in der Variable type_of_frame_rcvd.
  • Wenn in der Zeile 202 der Rahmen nicht als SNAP-Rahmen bestimmt wird, dann bestimmt in den Zeilen 210 der Router 80 aus dem DSAP-Feld des LLC-Kopfdatensatzes und aus einer Funktion lookup source addr() (suche Quelladresse) nach in dem LANSG 78 (welche die Liste von LANSG-Stationen absucht, indem sie nach einer Übereinstimmung zwischen einer Fernadresse in der Stations-Tabellen-Eingabe und der Quell-MAC-Adresse in dem Rahmen sucht), ob der Rahmen für das BNAv2-HRNP 42 auf dem Server 100 der A-Serie vorgesehen ist. Wenn ja, dann wird in der Zeile 212 der Rahmen als ein solcher durch Speichern eines entsprechenden Wertes in der Variable type_of_frame_rcvd identifiziert. Wenn der Rahmen nicht als ein BNAv2-Rahmen identifiziert wird, dann wird dem Rahmen ein Typ UNKNOWN in einer der Zeilen 214 zugewiesen.
  • Wenn in dem Schritt 200 der einkommende Rahmen keine kleinere oder mit 1500 Bytes gleiche Länge besitzt, dann wird davon ausgegangen, dass er entweder ein Ethernet-Rahmen oder ein großer BNAv2-Rahmen ist. In der Zeile 216 prüft der Router 80 das DSAP-Feld des LLC-Kopfdatensatzes des Rahmens, um zu bestimmen, ob er ein BNAv2-Rahmen sein könnte. Wenn ja, dann ruft in der Zeile 218 der Router 80 eine Funktion lookup_source_addr() auf, die ihm das Feld Quell_Adr des MAC-Kopfdatensatzes des Rahmens weitergibt, das aus dieser Information bestimmt, ob der Rahmen an das BNAv2-HRNP 42 auf dem Server 100 der A-Serie adressiert ist. Wenn ja, sendet die Funktion lookup_source_addr () einen Zeiger zu der Station zurück, die eine Verbindung zu diesem BNAv2-HRNP repräsentiert. Dann wird in der Zeile 220 die Variable type_of_frame_rcvd auf "BNA" gesetzt. Wenn jedoch kein BNAv2-HRNP in der Zeile 218 identifiziert wird, dann wird der Rahmen dem Typ UNKNOWN in der Zeile 222 zugewiesen.
  • Wenn in der Zeile 216 bestimmt wird, dass der Rahmen die Charakteristika eines BNAv2-Rahmens nicht besitzt, dann sollte er entweder ein IP-Rahmen oder ein ARP-Rahmen sein. In den Zeilen 224 bestimmt der Router 80 aus dem Typ-Feld des Ethernet-MAC-Kopfdatensatzes, welcher von diesen Rahmen-Typen tatsächlich empfangen worden ist. Wenn der Typ nicht bestimmt werden kann, wird der Rahmen einfach als ein Typ UNKNOWN identifiziert.
  • Wenn einmal der Typ des empfangenen Rahmens bestimmt wurde, muss der Rahmen zu dem geeigneten Netzwerkprotokoll-Provider geroutet werden. In dem Fall eines IP- oder ARP-Rahmens wird zuerst das Feld dest_addr (Ziel-Adresse) des IP-Kopfdatensatzes des Rahmens untersucht, um zu bestimmen, ob der Rahmen an sämtliche IP-Adressen auf dem Netzwerk (Zeile 226) "gesendet" (Broadcasting) werden soll. Wenn ja, dann wird eine Variable ip_addr_owner (IP-Adresse Inhaber) gesendet, um anzuzeigen, dass sowohl der Netzwerkprotokoll-Provider auf dem Server 100 der A-Serie (z. B. das TCP/IP-HRNP 44) als auch der Netzwerkprotokoll-Provider auf dem NT-Server 102 (z. B. das TCPIP.SYS 58) den Rahmen empfangen sollen. Wenn der Rahmen kein Broadcast-Rahmen ist, wird zuerst davon ausgegangen, dass er an keinen der Netzwerkprotokoll-Provider 44, 58 (Zeile 228) adressiert ist. In den Zeilen 230 bestimmt der Router 80, welcher der Netzwerkprotokoll-Provider 44, 58 den Rahmen empfangen soll und setzt dementsprechend die Variable ip_addr_owner. In den Zeilen 232 wird der Rahmen dann zu dem geeigneten Netzwerkprotokoll-Provider basierend auf dem Wert des ip_addr_owner geroutet. Wenn zum Beispiel der Rahmen an das TCP/IP-HRNP 44 auf dem Server der A-Serie geroutet werden soll, gibt der Router 80 den Rahmen an das LANSG-Modul 78 weiter, das in Kombination mit den anderen Komponenten der Verbindung den Rahmen an den Server 100 der A- Serie über die physikalische Verbindung zum Weiterleiten an diesen Netzwerkprotokoll-Provider weitergibt. Wenn anstatt dessen der Rahmen von dem Netzwerkprotokoll-Provider (dem TCPIP.SYS 58) auf dem NT-Server 102 empfangen werden soll, dann gibt der Router 80 den Rahmen an diesen Netzwerkprotokoll-Provider über geeignete Abrufe an die NDIS-Schnittstelle weiter. Wenn das ip_addr_owner anzeigt, dass keines der Netzwerkprotokoll-Provider dazu bestimmt wurde, der Empfänger des Rahmens zu sein, dann routet der Router 80 den Rahmen basierend auf den Werten der Eingaben EnableIPRoutingInMCP und EnanbleIPRouting in dem Windows NT-Register (oben beschrieben).
  • In dem Fall eines BNAv2-Rahmens (Zeilen 234) gibt der Router 80 den Rahmen an das LANSG-Modul 78 zusammen mit dem Zeiger auf die Station weiter, die eine Verbindung zu dem BNAv2-HRNP repräsentiert, das den Rahmen empfangen soll. In dem Fall eines Rahmen-Typs UNKNOWN (Zeilen 236) wird der Rahmen an die NDIS-Schnittstelle zum Handhaben von unbekannten Rahmen-Typen weitergeleitet.
  • Die 10A–10D umfassen Flussdiagramme, die eine weitere bevorzugte Ausführungsform der Routing-Funktionalität des Routers 80, sowie eine bevorzugte Ausführungsform des Verfahrens der vorliegenden Erfindung darstellen. In dieser Ausführungsform wird das "Rückschleife"-Merkmal unterstützt. Die 10A–10B stellen die von dem Router 80 ausgeführten Schritte dar, wenn ein Daten-Rahmen von dem Netzwerk 15 über das gemeinsam verwendete NIC 50 empfangen wird. Die 10C stellt die von dem Router 80 ausgeführten Schritte dar, wenn ein Daten-Rahmen von einem Netzwerkprotokoll-Provider auf dem Server 100 der A-Serie für die Ausgabe an das Netzwerk 15 über das gemeinsam verwendete NIC 50 gesendet wird. Die 10D stellt die ausgeführten Schritte dar, wenn ein Daten-Rahmen von einem Netzwerkprotokoll-Provider auf dem NT-Server 102 für die Ausgabe an das Netzwerk 15 über das gemeinsam verwendete NIC 50 gesendet wird.
  • Bezugnehmend auf die 10A–10B empfängt in dem Schritt 240 das NIC 50 einen einkommenden Rahmen von dem Netzwerk 15. In dem Schritt 242 ruft der NIC-Treiber 54 die NDIS-Schnittstelle ab, um ihm zu melden, dass ein Rahmen empfangen worden ist. In dem Schritt 244 ruft das NDIS sämtliche Protokoll-Treiber ab, die an das gemeinsam verwendete NIC 50 "gebunden" sind. In der vorliegenden Ausführungsform ist die JTD-Komponente 182 des Routers 80 ein derartiger gebundener Protokoll-Treiber. Wie oben erläutert wurde, erscheint die JTD-Komponente 182 dem NDIS als ein typischer Protokoll-Treiber.
  • In dem Schritt 246 wird der Rahmen in einen von dem LANSG-Modul 78 eingenommenen Puffer kopiert. Als Nächstes prüft in dem Schritt 252 der Router 80 die Ziel-MAC-Adresse in dem Rahmen, um zu bestimmen, ob sie mit der Broadcast-Adresse übereinstimmt. Wenn ja, schreitet die Steuerung zu dem Schritt 258 (10B). Wenn die Ziel-MAC-Adresse nicht die Broadcast-Adresse ist (Schritt 252), dann bestimmt in dem Schritt 254 der Router 80, ob die Ziel-MAC-Adresse mit der MAC-Adresse des NIC 50 übereinstimmt. Wenn nicht, dann prüft in dem Schritt 255 der Router 80, ob sich die Ziel-MAC-Adresse in der Multicast-Adressenliste des NIC befindet. Wenn nicht, dann wird der Rahmen in dem Schritt 256 verworfen. Wenn sich die Ziel-MAC-Adresse in der Multicast-Adressenliste des NIC befindet, dann schreitet die Steuerung zu dem Schritt 258 (10B).
  • Wenn in dem Schritt 254 festgestellt wird, dass die Ziel-MAC-Adresse mit der MAC-Adresse des NIC übereinstimmt, dann schreitet die Steuerung zu dem Schritt 258, worin der Router 80 (spezifisch die JTD-Komponente 182 in der 8 dargestellten Ausführungsform) aus dem Rahmen bestimmt, ob er für das BNAv2-HRNP 42 auf dem System der A-Serie vorgesehen ist. Wenn ja, wird der Rahmen von dem LANSG 78 an dieses BNAv2-HRNP über das HIF in dem Schritt 250 weitergegeben. Wenn der Rahmen für das BNAv2-HRNP 42 nicht vorgesehen ist, dann schreitet die Steuerung zu dem Schritt 258 der 10B.
  • Bezugnehmend nun auf die 10B bestimmt in dem Schritt 258 der Router 80, ob der Rahmen ein ARP-Rahmen ist. Wenn ja, dann ist er entweder eine ARP-Anforderung oder eine ARP-Antwort (bestimmt in den Schritten 260 bzw. 262). Wenn der Rahmen eine ARP-Anforderung ist, dann wird eine Kopie des Rahmens an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 in dem Schritt 268 geroutet, und der Rahmen selbst wird an das TCP/IP-HRNP 44 auf dem System der A-Serie über das HIF in dem Schritt 270 geroutet. Wenn der ARP-Rahmen eine ARP-Antwort ist, dann bestimmt in dem Schritt 264 der Router 80, ob die Ziel-Protokoll-Adresse mit der IP-Adresse des TCP/IP-HRNP 44 auf dem Server 100 der A-Serie übereinstimmt. Wenn ja, wird der Rahmen an diesen Netzwerkprotokoll-Provider über das HIF in dem Schritt 270 geroutet. Wenn nicht, wird der Rahmen über das NDIS an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 in dem Schritt 266 geroutet.
  • Wenn der Rahmen kein ARP-Rahmen, aber ein IP-Rahmen ist (Schritt 272), dann werden die Schritte 274 bis 278 ausgeführt, um zu bestimmen, ob die Ziel-IP-Adresse des IP-Rahmens entweder die Broadcast-Adresse (Schritt 274), die Netzwerk-IP-Adresse (Schritt 276) oder eine Multicast-Adresse der Klasse D ist (Schritt 278). Wenn die Ziel-IP-Adresse des IP-Rahmens irgendeine aus diesen ist, dann wird eine Kopie des Rahmens sowohl an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 über das NDIS (Schritt 268) als auch an das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie über das HIF geroutet (Schritt 270). Wenn in dem Schritt 272 bestimmt wird, dass der Rahmen kein IP-Rahmen ist, dann schreitet die Steuerung zu dem Schritt 266, worin der Rahmen nur an das NT-TCPIP.SYS 58 geroutet wird.
  • Wenn die Ziel-IP-Adresse keine von in den Schritten 274 bis 278 geprüften Typen ist, dann schreitet die Steuerung zu dem Schritt 280, worin der Router 80 bestimmt, ob die Ziel-IP-Adresse mit der des TCP/IP-HRNP 44 auf dem System der A-Serie übereinstimmt. Wenn ja, dann wird der Rahmen an diesen Netzwerkprotokoll-Provider über das HIF in dem Schritt 270 geroutet. Wenn nicht, dann prüft in dem Schritt 282 der Router 80 die Eingabe EnableIPRoutingInMCP in dem Windows NT-Register. Wenn diese Eingabe auf "Primär" gesetzt ist, dann wird der Rahmen an das TCP/IP-HRNP 44 auf dem System der A-Serie über das HIF in dem Schritt 270 geroutet. Wenn die Eingabe auf "Inaktiv" gesetzt ist, dann wird der Rahmen an den TCPIP.SYS-Treiber auf dem NT-Server 102 über das NDIS in dem Schritt 266 geroutet. Wenn die Eingabe EnableIPRoutingInMCP auf "Sekundär" gesetzt ist, dann schreitet die Steuerung zu dem Schritt 284, worin der Router 80 die Eingabe EnanbleIPRouting in dem Register prüft. Wenn die Eingabe EnanbleIPRouting auf "Wahr" gesetzt ist, dann wird der Rahmen an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 über das NDIS in dem Schritt 266 geroutet. Wenn die Eingabe EnanbleIP Routing auf "Falsch" gesetzt ist, dann wird der Rahmen an das TCP/IP-HRNP 44 auf dem Server 100 der A-Serie über das HIF in dem Schritt 270 geroutet.
  • Die 10C stellt die von dem Router 80 ausgeführten Schritte dar, wenn ein Rahmen enthaltender Datenblock, die über das NIC 50 ausgegeben werden sollen, über das HIF von einem Netzwerkprotokoll-Provider (z. B. entweder ein BNAv2-HRNP oder ein TCP/IP-HRNP) auf dem Server 100 der A-Serie gesendet wird. In dem Schritt 290 wird ein Datenblock von dem Netzwerkprotokoll-Provider auf dem NT-Server 102 über das HIF empfangen. In dem Schritt 292 wird der Datenblock in einer Warteschlange an das LANSG-Modul 78 gegeben. Wie in dem Schritt 294 angezeigt ist, werden die Schritte 296 bis 308 auf jeden Rahmen in dem empfangenen Block angewendet.
  • Für einen gegebenen Rahmen bestimmt in dem Schritt 296 das LANSG-Modul 78, ob der Rahmen von einem BNAv2-HRNP oder einem TCP/IP-HRNP stammt. Wenn der Rahmen ein BNAv2-Rahmen ist, dann hängt in dem Schritt 298 das LANSG-Modul 78 dem Rahmen BNA-Kopfdatensätze gemäß dem BNAv2-Protokoll vor, hängt die Verbindungsebene-Kopfdatensätze vor und liefert dann den Rahmen an das NDIS für die Ausgabe über das NIC 50 (Schritt 308).
  • Wenn anstatt dessen, der Rahmen von einem TCP/IP-HRNP stammt, dann hängt in dem Schritt 299 das LANSG-Modul 78 dem Rahmen das TCP/IP- und Verbindungsebene-Kopfdatensätze vor. Als Nächstes bestimmt in dem Schritt 300 der Router 80, ob die Ziel-MAC-Adresse die Broadcast-Adresse ist. Wenn ja, dann routet in dem Schritt 302 der Router 80 eine Kopie des Rahmens an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 über das NDIS, wie wenn der Rahmen von dem NIC 50 empfangen worden wäre. Als Nächstes wird in dem Schritt 308 der Rahmen ferner an das Netzwerk 15 über das gemeinsam verwendete NIC 50 geroutet.
  • Wenn die Ziel-MAC-Adresse des Rahmens nicht die Broadcast-Adresse ist, sondern anstatt dessen mit der Quell-MAC-Adresse übereinstimmt, dann routet in dem Schritt 306 der Router 80 den Rahmen an den TCPIP.SYS-Treiber 58 auf dem NT-Server 102 über das NDIS, wie wenn der Rahmen von dem NIC 50 empfangen worden wäre. Wenn die Ziel-MAC-Adresse des Rahmens weder mit der Broadcast-Adresse noch mit der Quell-MAC-Adresse übereinstimmt, dann wird der Rahmen einfach an das Netzwerk 15 über das gemeinsam verwendete NIC 50 in dem Schritt 308 geroutet. Man beachte, dass in der obigen Beschreibung die Schritte 302 und 306 die "Rückschleife"-Fähigkeit des Routers 80 der vorliegenden Erfindung repräsentieren.
  • Die 10D stellt die ausgeführten Schritte dar, wenn ein Rahmen für die Ausgabe von dem Netzwerkprotokoll-Provider (z. B. das TCP/IP.SYS 58) auf dem NT-Server 102 gesendet wird. Der ausgehende Rahmen wird über einen Abruf an die NDIS-Schnittstelle in dem Schritt 320 weitergegeben. In dem Schritt 322 liefert das NDIS den Rahmen an den Router 80 (spezifisch die JND-Komponente 184 in der Ausführungsform der 8). In dem Schritt 324 gibt die JND-Komponente 184 den Rahmen an die JTD-Komponente 182 weiter, die in der vorliegenden Ausführungsform ein Teil des LANSG-Moduls 78 ist. Als Nächstes wird in dem Schritt 326 der Rahmen in einen von dem LANSG 78 bereitgestellten Puffer kopiert.
  • Als Nächstes werden in dem Schritt 327 die Verbindungsebene-Kopfdatensätze von dem Rahmen isoliert. In dem Schritt 328 bestimmt der Router 80, ob eine Verbindung zu dem TCP/IP-HRNP auf dem Server 100 der A-Serie über das HIF offen ist. Wenn nicht, dann routet der Router 80 (spezifisch die JTD-Komponente 182) den Rahmen einfach an das NIC 50 über das NDIS in dem Schritt 338.
  • Wenn in dem Schritt 328 eine Verbindung zu dem TCP/IP-HRNP auf den Server 100 der A-Serie identifiziert wird, dann bestimmt in dem Schritt 330 der Router 80, ob die Ziel-MAC-Adresse des Rahmens mit der Broadcast-Adresse übereinstimmt. Wenn ja, dann wird in dem Schritt 332 eine Kopie der Rahmens an das TCP/IP-HRNP auf dem Server 100 der A-Serie über das HIF geroutet (wie wenn sie von dem NIC 50 empfangen worden wäre), und der Rahmen selbst wird an das NIC 50 über das NDIS in dem Schritt 338 geroutet. Wenn die Ziel-MAC-Adresse des Rahmens mit der Broadcast-Adresse nicht übereinstimmt, dann bestimmt in dem Schritt 334 der Router 80, ob die Ziel-MAC-Adresse mit der Quell-MAC-Adresse übereinstimmt. Wenn ja, dann wird in dem Schritt 336 der Rahmen nur an das TCP/IP-HRNP auf dem Server 100 der A-Serie über das HIF geroutet. Wenn die Ziel-MAC-Adresse des Rahmens weder mit der Broadcast-Adresse noch mit der Quell-MAC-Adresse übereinstimmt, dann wird der Rahmen nur an das NIC 50 über das NDIS in dem Schritt 338 geroutet. Man beachte wieder, dass in der obigen Beschreibung die Schritte 332 und 336 die "Rückschleife"-Fähigkeit des Routers 80 der vorliegenden Erfindung repräsentieren.
  • Wie das Vorangegangene darstellt, ist die vorliegende Erfindung auf Verfahren und Vorrichtungen ausgerichtet, die es einem ersten Netzwerkprotokoll-Provider, der auf einem ersten Computersystem ausgeführt wird und eine damit verknüpfte erste Netzwerkadresse besitzt, und einem zweiten Netzwerkprotokoll-Provider ermöglichen, der auf einem zweiten Computersystem ausgeführt wird und eine damit verknüpfte zweite Netzwerkadresse besitzt, dass beide Daten über ein Netzwerk mittels einer gleichen Netzwerk-Schnittstellenkarte senden und empfangen, die auf dem zweiten Computersystem installiert ist. Es wird verstanden, dass an den oben beschriebenen Ausführungsformen Veränderungen gemacht werden können, ohne von den breiten erfinderischen Konzepten abzuweichen. Während die vorliegende Erfindung oben in dem Zusammenhang eines Systems beschrieben ist, das einen Server der A-Serie und einen NT-Server umfasst, wird zum Beispiel verstanden, dass die Verfahren und Vorrichtungen der vorliegenden Erfindung mit beliebigen zwei Computersystemen des gleichen oder unterschiedlichen Typs verwendet werden können. Während in der am meisten bevorzugten Ausführungsform der Router 80 als eine JTD-Komponente und eine JND-Komponente umfassend beschrieben wird, können andere Ausführungsformen die Router-Funktionalität ferner als eine unterschiedliche Kombination von Komponenten oder als eine einzige Komponente implementieren. Zusätzlich ist die Verbindung der vorliegenden Erfindung auf die bestimmten offenbarten Ausführungsformen nicht beschränkt. Vielmehr beabsichtigt der Begriff "Verbindung", andere Verfahren und Vorrichtungen zum Übertragen von Daten zwischen den E/A-Teilsystemen der ersten und zweiten Computersysteme zu umfassen. Zum Beispiel erfordern andere Ausführungsformen vielleicht nicht die Funktionalität der QSP- und LANSG-Komponenten. Vielmehr könnte eine direktere Schnittstelle zwischen dem Verbindung-Gerätetreiber (ICD) und dem Router verwendet werden. Dementsprechend ist die vorliegende Erfindung auf die bestimmten offenbarten Ausführungsformen nicht beschränkt.

Claims (24)

  1. Eine Vorrichtung, die es einem ersten Netzwerkprotokoll-Provider (44) ermöglicht, der auf einem ersten Computersystem (100) ausgeführt wird und eine damit verknüpfte erste Netzwerkadresse besitzt, und einem zweiten Netzwerkprotokoll-Provider (58) ermöglicht, der auf einem zweiten Computersystem (102) ausgeführt wird und eine damit verknüpfte zweite Netzwerkadresse besitzt, dass beide auf ein Netzwerk (15) mittels einer gleichen Netzwerk-Schnittstellenkarte (50) zugreifen, die auf dem zweiten System installiert ist, folgendes umfassend: eine Verbindung (62, 64, 66, 70) (65, 67, 70')(63, 70'') zwischen einem Eingabe/Ausgabe-(E/A)-Teilsystem des ersten Computersystems und einem E/A-Teilsystem des zweiten Computersystems, über die Daten zwischen Systemen übertragen werden können; und einen Router (80), der auf dem zweiten Computersystem ausgeführt wird, der so ausgestaltet ist, dass er von der Netzwerkschnittstellenkarte empfangene Daten an den ersten Netzwerkprotokoll-Provider über die Verbindung weitergibt, wenn eine mit den Daten empfangene Netzwerkadresse mit der ersten Netzwerkadresse übereinstimmt, und der so ausgestaltet ist, dass er die empfangenen Daten an den zweiten Netzwerkprotokoll-Provider weitergibt, wenn die mit den Daten empfangene Netzwerkadresse mit der zweiten Netzwerkadresse übereinstimmt.
  2. Die Vorrichtung gemäß Anspruch 1, worin ferner der Router arbeitet, um Daten sowohl vom ersten Netzwerkprotokoll-Provider als auch vom zweiten Netzwerkprotokoll-Provider zum Netzwerk über die gleiche Netzwerk-Schnittstellenkarte auf eine Weise zu routen, die für beide Netzwerkprotokoll-Provider transparent ist.
  3. Die Vorrichtung gemäß Anspruch 1, worin, wenn einer der ersten und zweiten Netzwerkprotokoll-Provider so ausgestaltet ist, dass er Daten an den anderen adressiert, ferner der Router arbeitet, um diese Daten an den anderen Netzwerkprotokoll-Provider direkt weiterzugeben, wobei er die Netzwerk-Schnittstellenkarte auf eine Art und Weise umgeht, die für beide Netzwerkprotokoll-Provider transparent ist.
  4. Die Vorrichtung gemäß Anspruch 1, worin, wenn Daten über die Netzwerk-Schnittstellenkarte empfangen werden, die bestimmt sind, um an alle Netzwerkprotokoll-Provider gesendet zu werden, der Router so ausgestaltet ist, dass er derartige Daten erkennt und dass er sie sowohl an die ersten als auch zweiten Netzwerkprotokoll-Provider weitergibt.
  5. Die Vorrichtung gemäß Anspruch 1, worin, wenn einer der ersten und zweiten Netzwerkprotokoll-Provider auszugebende Daten sendet, die eine Broadcast-Adresse besitzen, der Router arbeitet, um diese Daten zum Netzwerk über die gleiche Netzwerk-Schnittstellenkarte zu routen und ferner diese Daten zum anderen Netzwerkprotokoll-Provider über die Verbindung zu routen.
  6. Die Vorrichtung gemäß Anspruch 1, worin der Router so ausgestaltet ist, dass er den Betrieb eines Netzwerkprotokoll-Providers simuliert, wenn er mit einem Gerätetreiber (54) der Netzwerk-Schnittstellenkarte verbunden ist, und der Router so ausgestaltet ist, dass er den Betrieb eines Gerätetreibers der Netzwerk-Schnittstellenkarte simuliert, wenn er mit den ersten und zweiten Netzwerkprotokoll-Providern verbunden ist, wodurch die Funktionalität des Routers für die Netzwerk-Schnittstellenkarte und die ersten und zweiten Netzwerkprotokoll-Provider transparent ist.
  7. Die Vorrichtung gemäß Anspruch 1, worin das zweite System einen NT-Server umfasst und worin die Netzwerk-Schnittstellenkarte einen Gerätetreiber (54) besitzt, der auf dem zweiten System installiert ist, der so ausgestaltet ist, dass er den Zugriff auf das NIC steuert, und worin ferner der NIC-Gerätetreiber und der Netzwerkprotokoll-Provider auf dem NT-Server zum Router über die Netzwerk-Treiber-Schnittstellen-Spezifikation (NDIS) verbunden ist.
  8. Die Vorrichtung gemäß Anspruch 1, worin der Router so ausgestaltet ist, dass er eine Tabelle erstellt und aufrechterhält, welche die Netzwerkadressen der ersten und zweiten Netzwerkprotokoll-Provider enthält.
  9. Die Vorrichtung gemäß Anspruch 1, worin der erste Netzwerkprotokoll-Provider eine Implementierung des TCP/IP-Protokolls auf dem ersten Computersystem umfasst und worin der zweite Netzwerkprotokoll-Provider eine Implementierung des TCP/IP-Protokolls auf dem zweiten Computersystem umfasst.
  10. Die Vorrichtung gemäß Anspruch 1, worin der erste Netzwerkprotokoll-Provider eine Vielzahl von Netzwerkprotokoll-Providern umfasst, wobei jeder eine damit verknüpfte Netzwerkadresse besitzt.
  11. Die Vorrichtung gemäß Anspruch 10, worin der erste Netzwerkprotokoll-Provider entweder einen TCP/IP-Netzwerkprotokoll-Provider (44) oder einen BNAv2-Netzwerkprotokoll-Provider (42) umfasst.
  12. Die Vorrichtung gemäß Anspruch 1, worin die Verbindung zwischen dem ersten Computersystem und dem zweiten Computersystem folgendes umfasst: eine physikalische Verbindung (62, 64, 66) (65, 67) (63) zwischen dem E/A-Teilsystem des ersten Computersystems und dem E/A-Teilsystem des zweiten Computersystems, über die Daten zwischen ihnen übertragen werden können; und einen Verbindung-Gerätetreiber (70) (70') (70'') auf dem zweiten Computersystem, der den Zugriff von weiteren Modulen (76, 78, 80, 82, 86, 88) auf dem zweiten Computersystem auf die physikalische Verbindung steuert.
  13. Die Vorrichtung gemäß Anspruch 12, worin die Verbindung zwischen den ersten und zweiten Computersystemen ferner einen Warteschlangen-Dienst-Provider (76) auf dem zweiten Computersystem umfasst, der so ausgestaltet ist, dass er Mehrfachdialoge zwischen Systemen über die physikalische Verbindung im Multiplex-Verfahren sendet.
  14. Die Vorrichtung gemäß Anspruch 12, worin das erste Computersystem einen Server der Unisys A-Serie umfasst und das zweite Computersystem einen NT-Server umfasst, und worin die physikalische Verbindung eine Verbindung (62, 64, 66) zwischen einer CS-Bus-Schnittstelle des E/A-Teilsystems des Servers der A-Serie und einen E/A-Bus des E/A-Teilsystems des NT-Servers umfasst.
  15. Die Vorrichtung gemäß Anspruch 14, worin der E/A-Bus des E/A-Teilsystems des NT-Servers einen EISA-Bus umfasst.
  16. Die Vorrichtung gemäß Anspruch 12, worin das erste Computersystem einen Server der Unisys A-Serie umfasst und das zweite Computersystem einen NT-Server umfasst, und worin die physikalische Verbindung eine Verbindung (65, 67) zwischen einem Anschluss einer Kanal-Verwaltungs-Einheit (CMU) (18b) des E/A-Teilsystems des Servers der A-Serie und einen E/A-Bus des E/A-Teilsystems des NT-Servers umfasst.
  17. Die Vorrichtung gemäß Anspruch 16, worin der E/A-Bus des E/A-Teilsystems des NT-Servers einen PCI-Bus umfasst.
  18. Die Vorrichtung gemäß Anspruch 12, worin das erste Computersystem, das einen Speicherbereich des ersten Computersystems einschließt, und sein E/A-Teilsystem (14') innerhalb des zweiten Computersystems emuliert sind, und worin die physische Verbindung (63) als eine Speicher-zu-Speicher-Verbindung zwischen dem Speicherbereich des emulierten ersten Computersystems und dem Speicherbereich des zweiten Computersystems emuliert ist.
  19. Die Vorrichtung gemäß Anspruch 12, worin der Verbindung-Gerätetreiber (70) (70') (70'') mit einem weiteren Modul (76) auf dem zweiten Computersystem über eine Prozeduren-Schnittstelle verbunden ist, in der Prozeduren des Verbindung-Gerätrtreibers und Prozeduren des anderen Moduls registriert werden, um die Funktionalität des Verbindung-Gerätetreibers vom anderen Modul zu isolieren, damit es gestattet wird, dass unterschiedliche physikalische Verbindungen mit entsprechend unterschiedlichen Verbindung-Gerätetreibern auf eine Art und Weise verwendet werden, die dem anderen Modul transparent ist.
  20. Ein Verfahren in einem System, das ein erstes Computersystem (100) und ein zweites Computersystem (102) umfasst, worin ein erster Netzwerkprotokoll-Provider (44) auf dem ersten Computersystem ausgeführt wird und eine damit verknüpfte erste Netzwerkadresse besitzt, und ein zweiter Netzwerkprotokoll-Provider (58) auf dem zweiten Computersystem ausgeführt wird und eine damit verknüpfte zweite Netzwerkadresse besitzt, und worin ferner eine Verbindung (62, 64, 66, 70) (65, 67, 70') (63, 70'') zwischen den ersten und zweiten Computersystemen ermöglicht, dass Daten zwischen ihnen übertragen werden, wobei das Verfahren dazu dient, es sowohl den ersten als auch zweiten Netzwerkprotokoll-Providern zu ermöglichen, auf ein Netzwerk mittels einer gleichen Netzwerk-Schnittstellenkarte zuzugreifen, die auf dem zweiten Computersystem installiert ist, wobei das Verfahren folgendes umfasst: das Routen von der Netzwerk-Schnittstellenkarte empfangener Daten an den ersten Netzwerkprotokoll-Provider über die Verbindung, wenn eine mit den Daten empfangene Netzwerkadresse mit der ersten Netzwerkadresse übereinstimmt; und das Routen der empfangenen Daten an den zweiten Netzwerkprotokoll-Provider, wenn die mit den Daten empfangene Netzwerkadresse mit der zweiten Netzwerkadresse übereinstimmt.
  21. Das Verfahren gemäß Anspruch 20, ferner das Routen von Daten von sowohl dem ersten Netzwerkprotokoll-Provider als auch dem zweiten Netzwerkprotokoll-Provider an das Netzwerk über die gleiche Netzwerk-Schnittstellenkarte auf eine Art und Weise umfassend, die für beide Netzwerkprotokoll-Provider transparent ist.
  22. Das Verfahren gemäß Anspruch 20, worin, wenn entweder der erste oder zweite Netzwerkprotokoll-Provider Daten an den anderen adressiert, das Verfahren ferner das Routen dieser Daten an den anderen Netzwerkprotokoll-Provider direkt über die Verbindung umfasst, wobei es die Netzwerk-Schnittstellenkarte auf eine Art und Weise umgeht, die für beide Netzwerkprotokoll-Provider transparent ist.
  23. Das Verfahren gemäß Anspruch 20, worin, wenn Daten über die gleiche Netzwerk-Schnittstellenkarte empfangen werden, die bestimmt sind, um an alle Netzwerkprotokoll-Provider auf dem Netzwerk gesendet zu werden, das Verfahren ferner das Routen derartiger Daten sowohl an den ersten Netzwerkprotokoll-Provider über die Verbindung als auch an den zweiten Netzwerkprotokoll-Provider umfasst.
  24. Das Verfahren gemäß Anspruch 20, worin, wenn einer der ersten und zweiten Netzwerkprotokoll-Provider auszugebende Daten sendet, die eine Broadcast-Adresse besitzen, das Verfahren ferner das Routen dieser Daten zum Netzwerk über die gleiche Netzwerk-Schnittstellenkarte und ferner das Routen dieser Daten zum anderen Netzwerkprotokoll-Provider Über die Verbindung umfasst.
DE69828602T 1997-06-02 1998-06-01 Von heterogenen rechnersystemen mitbenutzung einer netzschnittstellenkarte Expired - Fee Related DE69828602T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US4872397P 1997-06-02 1997-06-02
US48723P 1997-06-02
PCT/US1998/011201 WO1998056150A1 (en) 1997-06-02 1998-06-01 Shared use of a network interface card between heterogeneous computer systems

Publications (2)

Publication Number Publication Date
DE69828602D1 DE69828602D1 (de) 2005-02-17
DE69828602T2 true DE69828602T2 (de) 2005-12-29

Family

ID=21956113

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69828602T Expired - Fee Related DE69828602T2 (de) 1997-06-02 1998-06-01 Von heterogenen rechnersystemen mitbenutzung einer netzschnittstellenkarte

Country Status (4)

Country Link
EP (1) EP0986885B1 (de)
JP (1) JP3694532B2 (de)
BR (1) BR9809896A (de)
DE (1) DE69828602T2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4146426B2 (ja) * 2002-06-28 2008-09-10 パラ３、インコーポレイテッド コンピュータ・リソース利用方法および小型電子機器
JP4947913B2 (ja) * 2005-04-05 2012-06-06 キヤノン株式会社 通信装置及びその通信制御方法

Also Published As

Publication number Publication date
JP3694532B2 (ja) 2005-09-14
EP0986885B1 (de) 2005-01-12
BR9809896A (pt) 2000-08-01
JP2000513189A (ja) 2000-10-03
EP0986885A1 (de) 2000-03-22
DE69828602D1 (de) 2005-02-17

Similar Documents

Publication Publication Date Title
DE69928408T2 (de) Virtuelle transportschicht-schnittstelle und nachrichten untersystem für hochgeschwindigkeit-datenübertragung zwischen heterogenen computersystemen
DE112008002550B4 (de) Verfahren und System für virtuelle Schnittstellenkommunikation
DE60212626T2 (de) Endknotenunterteilung mittels lokaler identifikatoren
DE69922693T2 (de) Systemem und verfahren für netzwerkvorrichtung und ein-ausgabegerätetreiber
DE60201682T2 (de) Anordnung zur erzeugung mehrerer virtueller warteschlangenpaare aus einer komprimierten warteschlange auf der basis gemeinsamer attribute
DE69534411T2 (de) Offenes Transaktionverwaltungszugriffsystem und Verfahren
DE60024228T2 (de) Dynamische zuweisung verkehrsklassen an einer prioritätswarteschlange in einer paketbeförderungsvorrichtung
DE69430276T2 (de) Socketstruktur für gleichzeitigen Mehrfach-Protokollzugriff
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
DE69829346T2 (de) Ein-/Ausgabevorrichtung für ein Peripheriegerät
DE60032357T2 (de) Verbindungsarchitektur um minderbandbreitige verbindungen über eine hoch-bandbreitige verkettung zu verwalten
DE69837938T2 (de) Übergreifende bildung von server clustern mittels einer netzwerkflussvermittlung
DE60303026T2 (de) System, verfahren und produkt zur verwaltung des datenverkehrs in einem netzwerk
DE112014000415B4 (de) Quantisierte Überlastbenachrichtigung in einem virtuellen Netzwerksystem
DE60109709T2 (de) Datenverwaltungsrahmenwerk für Verfahrensverwaltung
DE69636369T2 (de) Virtuelles lokales netz für multi-emulatoren in einer offenen systemumgebung
DE60019640T2 (de) Digitales Rechnersystem und Verfahren zur Beantwortung von über ein externes Netzwerk empfangenen Anfragen
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
DE69930490T2 (de) Kommunikationsverfahren, Sendungsverfahren und Empfangsverfahren und Geräte zu ihrer Durchführung
DE60101566T2 (de) Gerätetreibererzeugung
DE10296675T5 (de) Virtuelles Vernetzungssystem und -verfahren in einem Verarbeitungssystem
DE112008003966T5 (de) Selektives Um-Abbilden einer Netzwerktopologie
CA2108126A1 (en) Method and apparatus for managing and facilitating communications in a distributed heterogeneous network
DE112004000122T5 (de) Vorrichtung und Verfahren zum Konfigurieren des Datenebenenverhaltens auf Netzwerkweiterleitungselementen
DE10205108A1 (de) System und Verfahren zum Zugreifen auf Softwarekomponenten in einer verteilten Netzwerkumgebung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee