Der Netzwerk-Manager

Dieses Kapitel beinhaltet die folgenden Themen:

Einführung
Aufgaben des Netzwerk-Managers
Mikrokernel/Netzwerk-Manager Schnittstelle
Netzwerktreiber
Knoten- und Netzwerk-Nummern
Ein Netzwerk wählen
TCP/IP-Netzwerke

Einführung

Der Netzwerk-Manager (Net) bietet QNX Benutzern eine nahtlose Erweiterung des leistungsstarken Nachrichtensystems des Betriebssystems. Indem der Netzwerk-Manager direkt mit dem Mikrokernel kommuniziert, erweitert er die IPC-Fähigkeiten von QNX an entfernte Maschinen. In Anlehnung daran bietet der Netzwerk-Manager drei komfortable Besonderheiten:

erhöhter Durchsatz durch Lastausgleich der Kommunikationspfade
Fehlertoleranz durch redundante Verbindungen
Überbrückung zwischen QNX Netzwerken

Aufgaben des Netzwerk-Managers

Der Netzwerk-Manager ist für die Auslieferung der QNX Nachrichten über ein lokales Netzwerk verantwortlich. Die Standard Nachrichten, welche lokal benutzt werden, müssen für den Nachrichtenaustauschen mit entfernten Prozessen nicht modifiziert werden. Mit anderen Worten, es gibt kein spezielles ``Netzwerk''Send(), Receive(), oder Reply().

Ein unabhängiges Modul

Der Netzwerk-Manager muß nicht in das Image des Betriebssystems eingebaut werden. Er kann jederzeit gestartet und angehalten werden, um Nachrichtenübermittlung im Netzwerk bereitzustellen oder zu entfernen.

Wenn der Netzwerk-Manager startet, registriert er sich beim Prozeß-Manager und dem Mikrokernel. Dadurch wird in diesen Modulen bestehender Code aktiviert, welcher sich mit dem Netzwerk-Manager verbindet. Das bedeutet, daß die Vermittlung von Nachrichten im Netzwerk und die Erzeugung entfernter Prozesse nicht einfach nur eine auf das Betriebssystem aufgesetzte Schicht ist. Die Nachrichtenübertragung im Netzwerk ist in das Herz der nachrichtenübermittelnden und prozeßverwaltenden Funktionen selbst integriert.

Diese tiefe, auf niedrigster Stufe implementierte Integration gibt QNX seine Netzwerktransparenz und qualifiziert es zu einem netzwerkweiten Betriebssystem. Da Applikationen durch das Übertragen von Nachrichten Zugriff auf alle Dienste haben und der Netzwerk-Manager Nachrichten transparent über das Netzwerk leitet, schließen sich QNX Knoten zu einem einzigen, logischen Computer zusammen.

Da der Netzwerk-Manager und der Mikrokernel voneinander deutlich getrennt sind, kann der Mikrokernel völlige Unabhängigkeit von der Netzwerkhardware erlangen, so daß netzwerklose Maschinen vom reduzierten Code-Umfang profitieren.

Mikrokernel-Netzwerk-Manager Schnittstelle

Der Mikrokernel und der Prozeß-Manager verbinden sich zum Netzwerk- Manager über eine spezielle, nichtblockierende Speicherwarteschlange. Diese ist eine Liste von durch den Netzwerk-Manager zu übertragenden Nachrichten. Die Einträge enthalten alle Informationen für eine ganz bestimmte Tätigkeit (z. B. Send(), Reply(), VC-Erzeugung, Bekanntgabe entfernter Signale, etc.).

Eine andere, vom Betriebssystem zur Breitstellung transparenter Nachrichtenübermittlung genutze Ressource, ist der virtuelle Verbindungspuffer. Zugeteilt, wenn ein Prozeß ein VC erzeugt, hält ein virtueller Verbindungspuffer die Daten bis zur Komplettierung einer Transaktion auf einem anderen Knoten bereit.

Die folgenden Diagramme stellen den Datenfluß und die Kontrolle für das Senden und Empfangen entfernter Nachrichten dar.

Eine Nachricht an einen entfernten Knoten senden

fig: images/sendrmot_de.gif

Ein Prozeß schickt ein Send() oder Reply() an einen entfernten Knoten.

Im Falle eins Send() oder Reply() an einen entfernten Knoten kommt es zu folgenden Ereignissen:

Der Prozeß ruft Send() oder Reply() auf und der Mikrokernel legt die Daten aus dem Datenraum des Prozesses in den virtuellen Verbindungspuffer, welcher mit dem durch Send() oder Reply() assoziierten VC spezifiziert wird.
Der Mikrokernel übergibt dem Netzwerk-Manager zeitlich geordnet einen Warteschlangeneintrag, welcher den Absender, den entfernten Empfänger und Zeiger auf die Daten im virtuellen Verbindungspuffer enthält. War die Warteschlange ursprünglich leer, wird die Proxy des Netzwerk- Managers ausgelöst, um bekanntzugeben, daß neue Arbeit angekommen ist.
Der Netzwerk-Manager entnimmt die Einträge aus der Warteschlange.
Der Netzwerk-Manager leitet die Einträge an einen geeigneten Netzwerktreiber weiter.
Der Netzwerktreiber beginnt mit der Verteilung auf die Netzwerkmedien und ist für die Auslieferung verantwortlich.

Im Falle einer Signalbekanntgabe oder beim Erzeugen eines VC wird der Prozeß- Manager, beziehungsweise der Mikrokernel, ein Kontrollpaket in die Warteschlange legen. Der Netzwerk-Manager wird dann das Paket an sein bestimmtes Ziel ausliefern.

Empfangen der Nachrichten auf dem entfernten Knoten

fig: images/recvrmot_de.gif

Ein Prozeß empfängt ein entferntes Send() oder Reply().

Davon ausgehend, daß der entfernte Knoten eine wie eben beschriebene Nachricht verschickt hat, werden auf dem empfangenden Knoten die folgenden Ereignisse eintreten:

Der Netzwerktreiber legt die Daten von den Netzwerkmedien in die entsprechenden virtuellen Verbindungspuffer.
Der Netzwerktreiber informiert den Netzwerk-Manager, daß das Datenpaket vollständig aufgenommen wurde.
Der Netzwerk-Manager nutzt einen privaten Kernelaufruf, um den Mikrokernel über den Empfang zu informieren.
Der Mikrokernel legt die Daten aus dem virtuellen Verbindungspuffer in den Puffer des Prozesses (vorausgesetzt er war auf dieser virtuellen Verbindung RECEIVE- oder REPLY-blockiert).

Alle Kontrollpakete, die der Netzwerk-Manager empfängt, werden unverzüglich an den Prozeß-Manager über Send() weitergeleitet. Diese Kontrollpakete werden für die Bekanntgabe von Signalen und für die VC-Erzeugung benutzt.

Netzwerktreiber

Wie der Dateisystem-Manager und der Geräte-Manager beinhaltet der Netzwerk-Manager keinen hardwarespezifischen Code. Diese Funktionalität wird durch die Treiber der Netzwerkkarten geliefert. Der Netzwerk-Manager kann viele Netzwerktreiber gleichzeitig unterstützen. Jeder Treiber unterstützt dabei typischerweise eine einzige Netzwerkkarte. Sie können gleiche oder unterschiedliche Treiber und Karten betreiben - zum Beispiel zwei Ethernetkarten und die entsprechenden Treiber oder vielleicht eine für Ethernet und eine für Arcnet.

Gemeinsam genutzte Speicherwarteschlangen liefern die Schnittstelle zwischen dem Netzwerk-Manager und den Treibern. Diese Schnittstelle wurde so ausgelegt,daß sie die maximale Durchsatzleistung erlangt. Der Treiber bestimmt das entsprechende Protokoll für die Netzwerkmedien.

Der Treiber ist verantwortlich für die Segmentierung, Sequenzialisierung und Wiederholung für den Fehlerfall. Dies ist der Standard für alle QNX Nachrichtenfunktionen. Dieser Entwurf erlaubt es QNX, neue Netzwerkhardware und Protokolle einfach zu unterstützen, indem nur ein Netzwerktreiber geschrieben, bzw. modifiziert wird.

Knoten- und Netzwerk-Nummern

Jeder Knoten in einem LAN wird durch zwei Nummern identifiziert:

seine physikalische Knoten ID (oder IDs, wenn der Knoten mehr als eine Netzwerkkarte hat)
eine Kombination aus seiner logischen Knoten ID und seiner logischen Netzwerk ID.

Physikalische Knoten ID

Die physikalische Knoten ID wird durch die Hardware vorgegeben. Netzwerkkarten kommunizieren miteinander, indem sie die physikalische Knoten ID des entfernten Knoten, mit dem sie verbunden werden möchten, angeben. Im Falle von Ethernet und Token Ring ist dies eine lange Nummer, welche für Anwender - und Werkzeuge - umständlich lang ist. Beispielsweise wird jede Ethernet und Token Ring Karte mit einer physikalischen, eindeutigen 48-Bit Knoten ID nach dem IEEE 802 Standard ausgeliefert. Arcnet Karten hingegen haben nur eine 8-Bit ID.

Physikalische Knoten IDs bringen einen signifikanten Nachteil mit sich: wenn einige Netzwerke untereinander kommunizieren, können die Adressen zu Konflikten führen (besonders im Falle von Arcnet) oder sie können von völlig unterschiedlichem Format sein.

Logische Knoten ID

Um die oben genannten Probleme mit physikalischen Knoten IDs zu umgehen, wird jedem QNX Knoten eine logische Knoten ID zugeordnet. Alle QNX Prozesse arbeiten mit logischen Knoten IDs. Die physikalischen Knoten IDs werden vor den Prozessen, welche auf QNX laufen, versteckt.

Logische Knoten IDs vereinfachen die Lizensierung von Netzwerken und Applikationen. Sie machen es auch einigen Werkzeugen einfacher, daß Netzwerk zu analysieren wenn sie nur die IDs von 1 bis zur Anzahl Knoten im Netz durchsuchen müssen.

Die Zuordnung zwischen logischen und physikalischen Knoten IDs geschieht durch den Netzwerk-Manager. Dem Treiber wird eine physikalische ID durch den Netzwerk-Manager übergeben, sobald er Daten an einen anderen Knoten ausliefern soll.

Die logische Knoten ID wird typischerweise durch sequentielle Ziffern, beginnend mit 1, vergeben. Ein Knoten mit einer Ethernetkarte könnte zum Beispiel eine logische Knoten ID von 2 haben, welche der physikalischen Knoten ID von 00:00:c0:46:93:30 entspricht.

Beachten Sie, daß die logische Knoten ID für alle Knoten in allen miteinander verbundenen QNX Netzwerken eindeutig sein muß, um zu garantieren, daß die Netzwerke miteinander arbeiten und auch Datenpakete über andere QNX-Knoten weitergeleitet werden können.

Logische Netzwerk ID

Die Netzwerk ID identifiziert ein einziges logisches Netzwerk. Ein logisches Netzwerk bildet jede Hardware, welche es einem Netzwerktreiber erlaubt, direkt mit einem anderen Netzwerktreiber auf einem anderen Knoten zu kommunizieren. Das kann so einfach wie ein serieller Anschluß oder so komplex wie ein Ethernet Netzwerk mit Hardware-Bridges sein.

Im folgenden Diagramm hat Knoten 7 zwei Netzwerkkarten, welche es dem Knoten erlauben, Knoten auf dem logischen Netzwerk 1 und 2 anzusprechen. Die Knoten 8 und 9 haben beide drei Karten, welche sie mit den Netzwerken 1, 2 und 3 verbinden.

Beachten Sie, daß jede logische Knoten ID in allen drei logischen Netzwerken eindeutig ist.

Logische Netzwerk- und Knoten-IDs werden durch den Systemadministrator vergeben. Um mehr Informationen zu erhalten, lesen Sie bitte über die Netzwerkinstallation im Handbuch Installation & Konfiguration.

fig: images/multinet_de.gif

Viele physikalische Netzwerke existieren nebeneinander durch Verwendung logischer Netzwerke.

Entscheidung für ein Netzwerk

In dem Fall, daß Knoten durch mehr als ein logisches Netzwerk verbunden sind, hat der Netzwerk-Manager die Wahl, welches Netzwerk er benutzt, wenn er an einen entfernten Knoten ausliefern muß. Im oben dargestellten Diagramm zum Beispiel, könnte Knoten 7 an Knoten 8 ausliefern, indem er entweder den Treiber des logischen Netzwerkes 1 oder des logischen Netzwerkes 2 benutzt.

Lastverteilung

Der Durchsatz in einem Netzwerk wird durch eine Kombination aus Computer- und Netzwerkgeschwindigkeit bestimmt. Wenn Ihr Computer Daten schneller liefern kann als das Netzwerk sie akzeptieren kann, wird dieses Ihren Durchsatz einschränken.

Zwei Pentium Computer, durch ein 10BASE-T Ethernet Netzwerk verbunden, werden auf ein Maximum von 1.1 Millionen Bytes pro Sekunde limitiert. Das ist die Datenrate, welche von der Ethernethardware unterstützt wird. Wenn Sie aber zwei Ethernetkarten in jeden Computer stecken und diese mit zwei separaten Kabeln verbinden, könnte der Netzwerk- Manager Daten über beide Netzwerke simultan versenden. Bei hohen Geschwindigkeitsanforderungen würde das bis zu einem doppelten Durchsatz eines einzelnen Netzwerkes führen.

Der Netzwerk-Manager balanciert den Ladevorgang automatisch aus, indem er einen entsprechenden Netzwerktreiber auswählt. Wenn gerade eine Übermittlung von Knoten 7 zu Knoten 8 auf dem logischen Netzwerk 1 stattfindet, und eine weitere Übertragung zu Knoten 8 von Knoten 7 erfolgen muß, wird das logische Netzwerk 2 automatisch gewählt, um die Daten zu transportieren.

Fehlertoleranz

Wenn Knoten über zwei oder mehrere Netzwerke verbunden sind, gibt es mehr als nur einen Weg, um zu kommunizieren. Sollte in einem Netzwerk eine Karte einen Fehler verursachen und dadurch jede Kommunikation auf diesem Netzwerk verhindern, wird der Netzwerk-Manager automatisch alle Daten über ein anderes Netzwerk umleiten. Dies geschieht automatisch, ohne jede Einbeziehung der Applikationssoftware. Das Ergebnis ist eine transparente Netzwerk-Fehlertoleranz. Wenn Kabel der unterschiedlichen Netzwerke über verschiedene Wege geführt werden, sind Sie zusätzlich noch vor unbeabsichtigten Kabeldefekten geschützt.

Sie können auch ein Tandemsystem konstruieren, indem Sie zwei Maschinen zum einen durch ein schnelles Netzwerk für den normalen Betrieb und zum anderen durch ein billigeres, langsameres Netzwerk (z. B. eine serielle Verbindung), welches im Stand-By-Betrieb verbleibt, verbinden. Wenn das erste Netzwerk einen Fehler aufweist, bleibt die Kommunikation erhalten, wenn auch der Durchsatz natürlich verringert wird.

Brücken zwischen QNX LANs

Der Netzwerk-Manager erlaubt jedem Knoten, sich wie eine Brücke zwischen zwei separaten IEEE 802-basierenden QNX-Netzwerken zu verhalten.

Da QNX dasselbe Paketformat und Protokoll auf allen IEEE 802-basierenden Netzwerken benutzt, können Sie Brücken zwischen Ethernet, Token Ring, und FDDI Netzwerken erzeugen.

Arcnet Netzwerke können nicht überbrückt werden.

Betrachten Sie das folgende Diagramm, in welchem Knoten 17 und Knoten 18 auf dem einen Netzwerk liegen und Knoten 18 und Knoten 19 auf einem anderen:

fig: images/relay_de.gif

Netzwerküberbrückung zwischen zwei IEEE 802-basierenden QNX LANs.

Knoten 17 und 18 liegen im gleichen Netzwerk, können also direkt miteinander kommunizieren. Das Gleiche gilt für Knoten 18 und 19. Aber wie kann Knoten 17 mit Knoten 19 kommunizieren?

Da beide betroffenen LANs auf IEEE 802 basieren, überbrückt Knoten 18 automatisch Pakete und erlaubt Knoten 17 und Knoten 19 eine virtuelle Verbindung zu erzeugen. Obwohl sie nicht an das gleiche LAN angebunden sind, können Knoten 17 und 19 so miteinander kommunizieren, als ob sie es wären.

TCP/IP-Netzwerke

Die ``angeborene'' Netzwerk-Unterstützung von QNX implementiert ein LAN, welches sich auf sein eigenes geschützes Protokoll verläßt und so optimiert ist, daß es eine schnelle, nahtlose Schnittstelle zwischen QNX Computern liefern kann. Um aber mit nicht-QNX Systemen zu kommunizieren, benutzt QNX den Industrie-Standard für Netzwerkprotokolle, welcher kollektiv als TCP/IP bekannt ist.

Seit das Internet so gewachsen ist, daß es mehr und mehr in unserem täglichen Leben sichtbar wird, ist das auf - IP (Internet Protokoll) - basierende Protokoll zunehmend wichtiger geworden. Selbst wenn Sie nicht an "Das Internet" angebunden sind, sind das IP Protokoll und die dazugehörenden Werkzeuge allgegenwärtig. Sie machen IP zu der de facto Wahl für viele private Netzwerke.

IP wird für alles, beginnend bei einfachen Tasks (z. B. entferntes Anmelden) bis hin zu komplizierten Tasks (z. B. die Auslieferung von Echtzeit-Börsenkursen) benutzt. Mehr und mehr Unternehmen hängen sich an das World Wide Web, welches allgemein auf IP läuft, um mit Ihren Kunden zu kommunizieren, zu werben und andere geschäftlichen Kontakte zu pflegen.

TCP/IP-Manager

Der QNX-TCP/IP-Manager wurde vom Berkeley BSD 4.3 Stack hergeleitet, welcher der verbreitetste TCP/IP-Stack im Internet ist und als Basis für viele Systeme genutzt wird.

Socket API

Die BSD Socket API war die offensichtliche Wahl für QNX 4. Die Socket API ist die Standard API für TCP/IP-Programmierung in der Unix Welt. In der Windows Welt basiert die Winsock API darauf und teilt eine Menge mit der BSD Socket API. Das macht die Portierung zwischen den beiden Systemen sehr einfach.

Alle Routinen, die ein Applikationsentwickler erwarten würde, sind verfügbar, einschließlich:

accept()
bind()
bindresvport()
connect()
dn_comp()
dn_expand()
endprotoent()
endservent()
gethostbyaddr()
gethostbyname()
getpeername()
getprotobyname()
getprotobynumber()
getprotoent()
getservbyname()
getservent()
getsockname()
getsockopt()
herror()
hstrerror()
htonl()
htons()
h_errlist()
h_errno()
h_nerr()
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
ioctl()
listen()
ntohl()
ntohs()
recv()
recvfrom()
res_init()
res_mkquery()
res_query()
res_querydomain()
res_search()
res_send()
select()
send()
sendto()
setprotoent()
setservent()
setsockopt()
shutdown()
socket()

Die allgemeinen Dämonprozesse und Werkzeuge aus dem Internet lassen sich einfach in diese Umgebung portieren oder einfach kompilieren. Dies macht alles, was für Ihre Applikationen bereits existiert, ohne große Anstrengung verfügbar.

Netzwerk-Interoperabilität

Der QNX-TCP/IP-Manager wurde mit äußerster Interoperabilität im Hinterkopf entwickelt und implementiert. Der Code lehnt sich sowohl an die RFCs als auch an die Praxis an. Der TCP/IP-Manager spricht all die in RFC 1122 vorgeschlagenen Funktionalitäten an. Die ARP, IP, ICMP, UDP, und TCP Protokolle werden ebenfalls unterstützt.

NFS

Das Netzwerk-Dateisystem (Network FileSystem, NFS) ist eine TCP/IP-Applikation, welche in den meisten DOS- und Unix-Systemen implementiert wurde. NFS läßt Sie entfernte Dateisysteme - oder Teile von ihnen - auf Ihren lokalen Namensraum verpflanzen. Dateien auf entfernten Systemen erscheinen somit als Teile Ihres lokalen QNX Dateisystems.

In QNX 4 benötigt NFS den Socket-Manager. Beachten Sie, daß eine "leichtere" Version des Socket-Managers, bekannt als Socklet, ebenfalls verfügbar ist, wenn Sie NFS nicht benötigen.

SMB

QNX unterstützt auch das Server-Message-Block-Protokoll (SMB), welches von unterschiedlichen Servern wie Windows NT, Windows 95, Windows for Workgroups, LAN Manager und Samba benutzt wird. Das SMBfsys Dateisystem erlaubt einem QNX Client einen transparenten Zugriff auf entfernte Laufwerke, welche sich in diesen Servern befinden.

Kapitel 7 - Der Netzwerk-Manager