Netzwerkfunktionen von Windows NT

von Thomas Bätzler, Thomas@Baetzler.de

Einleitung

Windows NT stellt einen großen Einschnitt in der Entwicklung der Windows-Produkte von Microsoft dar: Revolution statt Evolution war das Schlagwort, mit dem die Ära des ersten Microsoft-Betriebssystems eingeläutet wurde. Dem Projekt kam zugute, daß DEC gerade die Entwicklung seines Betriebssystems VMS gestoppt hatte, so daß eine Menge hochqualifizierter Spezialisten verfügbar waren, die den Kern der Entwicklertruppe bildeten. Das Ziel ihrer Bemühungen war ein Betriebssystem, das den folgenden Kriterien genügte: Die Netzwerkkomponenten von NT wurden von der Entwicklergruppe um Dave Thompson entworfen umd umgesetzt. Ihr Hauptaugenmerk galt der flexiblen Unterstützung von Netzwerkhardware und Transportprotokollen. Windows NT sollte nicht nur mit den bisherigen LAN Manager- und Windows-Netzwerken vernetzbar sein, sondern auch an beliebige andere Netze Anschluß finden können. Dazu wurde in NT ein ``Plug'n'Play''-Konzept genutzt, bei dem Treiber bei Bedarf nachgeladen werden können. Für die unter NT laufenden Applikationen sollte diese Unterstützung jedoch transparent bleiben, so daß es für Anwendungen keinen Unterschied macht, wenn beispielsweise auf einen Novell-Fileserver oder ein per NFS gemountetes Dateisystem zugegriffen wird. Windows NT unterstützt sowohl Peer-to-Peer Netzwerke von Workstations, als auch ``klassische'' Client/Server-Netze mit einem oder mehreren dedizierten Server-Rechnern. Für Client-Rechner und Stand-alone-Systeme im Peer-to-Peer Netzwerk wird Windows NT Workstation angeboten, während für Server das Betriebssystem Windows NT Advanced Server (NTAS) angeboten wird. Im Vergleich mit dem Workstation-Betriebssystem bietet die Server-Version erweiterte und zusätzliche Dienste wie uneingeschränktes File- und Print-Serving und Domänenverwaltung. Server und Clients müssen nicht unbedingt am gleichen lokalen Netz arbeiten: Mit dem Remote Access Service kann Windows NT auch Netzwerkverbindungen über Modem- und ISDN-Leitungen aufbauen. Da hier Standardprotokolle wie PPP oder SLIP eingesetzt werden, ist auch eine Verbindung zu einem Nicht-NT-Rechner möglich. Während über SLIP nur TCP/IP transportiert werden kann, unterstützt PPP zusätzlich auch NetBEUI und IPX/SPX. NT sollte auch die Möglichkeiten bieten, verteilte Anwendungen zu programmieren. Hierzu bietet es einen transparenten RPC Dienst, aber auch Sockets, die NetBIOS- und WNet-Programmierschnittstellen, sowie die bei Lan-Manager-Netzen üblichen ``Named Pipes'' und Mailslots.

Die Netzwerkkomponenten von NT

Im ISO/OSI-Modell lassen sich die Netzwerkkomponenten von Windows NT wie folgt einordnen: Das Schaubild auf der nächsten Seite zeigt diese Komponenten im Modell in der Übersicht. Sowohl Netzwerkkartentreiber als auch Protokollstacks sind unter NT so implementiert, daß sie bei Bedarf geladen bzw. entladen werden können. Des weiteren sorgen die Schnittstellen NDIS und TDI dafür, daß Treiber für Netzwerkkarten oder Protokollstacks nach Bedarf miteinander kombiniert werden können. Die Kopplung der Komponenten erfolgt durch das sogenannte ``Binding'', das festlegt, welche Protokolle welchen Netzwerktreiber benutzen sollen. Es sind auch Mehrfachbindungen in beide Richtungen möglich, so daß ein Protokoll einerseits auf mehreren Netzwerken gefahren werden kann, aber andererseits auch mehrere Protokolle auf einen Netzwerktreiber zugreifen können.

Redirector und Server

Die Redirector und Server von Windows NT sind als Dateisystemkomponenten Teil des im Betriebssystemkern befindlichen I/O-Managers. Ihre Aufgabe ist es, Anfragen nach entfernten Objekten aufs Netz zu schicken, bzw. solche Anfragen an lokale Ressourcen weiterzuleiten. Jeder Protokollstack besitzt hierfür seinen eigenen Redirector, bzw. Server. Nach oben bildet eine protokollspezifische Provider-DLL wieder eine einheitliche Schnittstelle an, über die Redirector und Server angesprochen werden können. Server und Redirector realisieren die grundlegende Funktionalität des Windows-Netzwerks. Auf dem Session-Layer findet die virtuelle Kommunikation zwischen ihnen ungeachtet des benutzten Transportprotokolls mit ``Server Message Blocks'' (SMB) genannten Nachrichten statt. Im Windows-Netzwerk erbringen diese Komponenten Session-, File, Printer und Message-Dienste. Die Zuteilung von Netzwerkanfragen an einen Redirector erfolgt bei Windows NT durch eine von zwei Entitäten: Zum einen durch den ``Multiple Provider Router'' (MPR) und zum anderen durch den durch den ``Multiple UNC Provider'' (MUP).

Der Multiple Provider Router

Der MPR ist dabei für Zugriffe zuständig, die durch die Windows Netzwerk (WNet) API entstehen. Er reicht eingehende Anfragen der Reihe nach an die aktiven Provider weiter, bis der zuständige Redirector gefunden wurde, der die Kommunikation übernimmt.

Der Multiple UNC Provider

Der MUP löst Anfragen auf, die durch Dateizugriffe in der Uniform Naming Convention (UNC) entstehen. Die UNC bildet entfernte Ressourcen in einen logischen Namensraum ab. Ein UNC-Name besteht aus dem Namen des entfernten Rechners, dem zwei Rückstriche vorangestellt wurden, sowie Ressourcenname und weiteren Parametern, die durch jeweils vorangestellte Rückstriche getrennt sind. Der UNC-Name für die Datei ``TEST'' im Verzeichnis ``PUB'' auf einem vom Rechner ``VESTA'' unter dem Namen ``SHARE'' exportierten Dateisystem wäre somit also ``\\VESTA\SHARE\PUB\TEST''.

IPC-Mechanismen

Das Schaubild 1.2 zeigt die netzwerkweiten IPC-Mechanismen von Windows NT im Überblick: Eine Besonderheit von Windows NT ist die Windows-Socket-Schnittstelle, die alle verfügbaren Protokollstacks direkt als Transport nutzen kann, ohne daß hierzu ein eigener Redirector verfügbar sein muß. Dies ist ein wesentlicher Unterschied zu traditionellen NetWare- oder UNIX-Umgebungen, wo Sockets nur zusammen mit dem Transportmedium TCP/IP verfügbar sind. IPXDECnetDECnet Named Pipes und Mailslots sind zwei weitere Mechanismen, die zusammen mit den Windows Sockets als Transportmedium für den Remote Procedure Call (RPC) genutzt werden können. Auch sie sind vollkommen vom verwendeten Transportprotokoll unabhängig.

Named Pipes

Named Pipes werden vom Server angelegt,und können dann von einem oder mehreren Clients geöffnet werden. Die Pipe wird dabei als UNC-Name spezifiziert, wobei die erste Komponente nach dem Rechnernamen ``pipe'' lautet. Diese Pipes können dann zur bidirektionalen Kommunikation genutzt werden. Da Pipes wie normales Dateien angelegt werden, ist der verwendete Transport für sie vollkommen transparent --- es muß nur ein entsprechender Redirector vorhanden sein.

Mailslots

Mailslots sind im Gegensatz zu Named Pipes unidirektional und verbindungslos. Zum Datentransport werden unbestätigte Datagramme als Broadcast verschickt. Die Datensicherung ist hier Aufgabe der Applikation. Mailslots werden ähnlich wie Named Pipes durch einen UNC-Namen spezifiziert; mit dem Unterschied, daß hier als erste Komponente die Empfängerspezifikation steht und danach die Komponente ``mailslot'' sowie der Bezeichner des Mailslots folgen. Empfänger können sein: Mailslots sind als IPC-Mechanismus also vor allen Dingen dann geeignet, wenn ein Server mehrere Clients mit minimalem Aufwand erreichen will und wenn ein eventueller Datenverlust ohne Konsequenzen ist.

Windows Sockets

Da Windows Sockets unter Windows NT auf mehreren Transportprotokollen aufbauen können, liegt der wesentliche Unterschied zu den Unix-Sockets in der größeren Anzahl von Adressfamilien, die unterstützt werden, sowie in deren Adressdarstellung. Wo bei TCP/IP eine Netzwerkadresse und Portnummer angegeben wird, muß für NetBEUI ein maximal 15 Zeichen langer NetBIOS-Name angegeben werden. IPX/SPX wiederum erwartet neben dem Port eine Netz- und eine Knotennummer für der Rechner, der den Socket bekommen soll. Da die Sockets direkt auf den Transportprotokollen aufsetzen, haben sie einen nur sehr geringen Overhead. Programme, die Sockets nutzten, müssen aber auf das Netzwerk abgestimmt werden, auf dem sie laufen sollen.

Remote Procedure Call

Auch beim RPC spielt das zugrundeliegende Transportprotokoll eine Rolle: Der RPC-Server kann sein Interface für eines oder mehrere der aktiven Protokolle registrieren lassen. Eine Kommunikation zwischen RPC-Client und Server kommt nur zustande, wenn beide über ein gemeinsames Transportmedium kommunizieren können. Die Highlevel-Schnittstelle RPC bietet als einen Vorzug transparente Datenumsetzung zwischen Hosts mit verschiedener Byte-Ordnung.

Arbeitsgruppen und Domänen

Kleine Windows NT-Netzwerke ohne dedizierten Server können zu Arbeitsgruppen zusammengefaßt werden. Innerhalb einer solchen Arbeitsgruppe verwaltet jeder Rechner seine eigenen Zugangsberechtigungen. Exportierte Ressourcen wie Shares oder Netzdrucker können zusätzlich durch ein Paßwort abgesichert werden. Feinere Sicherungsmechanismen sind nicht vorhanden. Sind mehr als nur einige wenige Rechner in einer Arbeitsgruppe, dann steigt vor allem der Aufwand zur Administration der Zugangsberechtigungen ins Gigantische, denn schließlich müssen alle Zugangsberechtigungen auf allen Rechnern den gleichen Stand haben, wenn jeder Anwender auf alle Ressourcen Zugriff haben soll. In so einem Fall empfiehlt es sich, die Arbeitsgruppe zur Windows NT-Domäne umzukonfigurieren. Domänen und Arbeitsgruppen ist gemeinsam, daß es sich um administrative, und nicht um technische Organisationsformen handelt. Eine Domäne kann sich über mehrere Subnetze erstrecken; es können aber auch Rechner aus mehreren verschiedenen Domänen im selben Subnetz sein. Die Domäne ist dadurch gekennzeichnet, daß bei ihr Zugangsberechtigungen zentral auf einem Server, dem ``Primary Domain Controller'' (PDC) verwaltet werden. Zur Erhöhung der Sicherheit und der Verfügbarkeit gibt es oft auch einen oder mehrere ``Backup Domain Controller'' (BDC), die diese Daten vom PDC duplizieren. Wenn sich ein Anwender an einem Rechner der Domain bei der Domain anmeldet, so wird sein Zugang vom PDC oder BDC validiert. In einer einfachen Domäne können bis zu 10.000 Benutzer verwaltet werden --- für größere Benutzerzahlen gibt es entsprechende Sonderlösungen.

Vertrauen zwischen Domänen

Eine Domäne kann einer anderen Domäne ``vertrauen'' und so den Benutzern der anderen Domäne Zugriff auf die Ressourcen der eigenen Domäne geben. Wenn Domäne A also Domäne B vertraut, dann darf ein Benutzer von B Umgekehrt hat ein Benutzer der Domäne A keine Rechte in und keinen Zugang zur Domäne B, solange das Vertrauensverhältnis nur einseitig erklärt wurde. Das Vertrauensverhältnis ist auch nicht transitiv, so daß Benutzer einer Domäne C, der die Domäne B vertraut, keine Rechte in der Domäne A haben, auch wenn A B vertraut.

Verbreitete Domänenmodelle

Je nach administrativen Anforderungen und Netzwerkgröße gibt es verschiedene Möglichkeiten, eine Domäne anzulegen.

Single-Domain-Modell

Das einfachste Domänenmodell ist das Single-Domain-Modell, bei dem alle Rechner im Netzwerk Teil einer einzigen Domäne sind. Da es nur eine einzige Domäne gibt, müssen keine Vertrauensverhältnisse administriert werden. Allerdings ist die Benutzerzahl durch die Limitierungen des PDC beschränkt.

Master-Domain-Modell

Oftmals ist aber auch gewünscht, daß einzelne Abteilungen einer Firma ihre Ressourcen selbst administrieren: Für einen solchen Fall eignet sich das Master-Domänen-Modell, bei dem es eine Hauptdomäne gibt, der alle anderen Domänen trauen. Die Benutzer und Benutzergruppen sind nur in der Hauptdomäne definiert und können so zentral administriert werden. Die Zahl der Benutzer ist allerdings auch hier begrenzt.

Multiple-Master-Domain-Modell

Diese Beschränkung umgeht man mit dem Multiple-Master-Domain-Modell, bei dem mehrere Master-Domains existieren, in denen die Benutzer definiert sind. Die Master Domänen vertrauen sich alle wechselseitigt und sind die vertrauten Domänen aller Unterdomains.

Vollständige Vertrauensstellung

Bei diesem Modell vertraut jede Domände der Organisation jeder anderen Domäne. Jeder Administrator kann seine eigenen Benutzerkonten und globale Benutzergruppen definieren. Den Benutzern steht der Zugriff zu allen Ressourcen im Netz offen. Bei sehr großen Domänen ist dieses Modell aber wegen der Vielzahl an Vertrauensverhältnssen sehr komplex zu administrieren.

Lokale und Globale Gruppen

Windows NT kennt wie Unix auch das Konzept von Benutzergruppen, um die Administration zu vereinfachen. Es wird jedoch zwischen lokalen Gruppen und globalen Gruppen unterschieden. Lokale Gruppen gelten immer nur innerhalb einer Domäne. Eine Gruppe kann weitere Gruppen und Benutzer der eigenen Domäne als Mitglieder enthalten. Wie erteilt nun eine vertrauende Domäne den Benutzer einer anderen Domäne Rechte? Windows NT bietet hierfür die globalen Benutzergruppen an, die auf allen einander vertrauenden Domänen verfügbar sind. Im Gegensatz zu lokalen Gruppen können nur Benutzer Mitglieder einer globalen Gruppe werden. Es ist nicht möglich, wie bei lokalen Gruppen auch andere Gruppen in die Gruppe zu übernehmen.

Zugangsberechtigungen und Authentisierung

Wenn ein Benutzer sich an einer Arbeitsstation einloggt, die einer Domäne angehört, so hat er die Wahl, sich entweder lokal am Rechner oder sich bei der Domäne anzumelden. Vertraut die Domäne anderen Domänen, so kann sich der Benutzer auch an einer dieser Domänen anmelden. Ist der Benutzer nur lokal eingeloggt, so wird sein Zugang beim Zugriff auf Ressurcen der Domäne mit seinem aktuellen Benutzernamen und Kennwort nachträglich authentisiert. Ein potentielles Problem besteht darin, daß der Benutzer unterschiedliche Kennwörter für sein lokales und das Domain-Login verwendet: Er kann dann nicht auf die entfernten Ressourcen zugreifen. Beim Einloggen in die Domäne verwendet Windows NT die sogenannte ``Pass Through Authentication'', bei der der Zugang nicht vom lokalen Rechner, sondern vom PDC oder einem der BDC validiert wird. Meldet er sich bei einer vertrauten Domain an, so wird sein Login an den PDC seiner Heimatdomain übergeben.

Ressourcenauswahl in der Domain

Die Server und Peers einer Domain stellen mit ihren exportierten Dateisystemen, Druckern und Schnittstellen Ressourcen zur gemeinsamen Nutzung zur Verfügung. Das Windows-Netzwerk bietet über die UNC eine einfache Methode zur Adressierung dieser Ressourcen. Wie findet aber ein Anwender heraus, welche Ressourcen zu seiner Verfügung stehen? Windows NT bietet hierzu den ``Computer Browser Service'' an. Dieser Dienst wird von einem als ``Master Browser'' designierten Rechner und seinen ``Backup Browsers'' erbracht. Der Master Browser führt dabei Buch, welcher Rechner welche Ressourcen zur Verfügung stellt, während die Backup Browser diese Liste von ihm beziehen und ihren Clients anbieten. Der Master Browser kann seine Browse-Liste auf mehrere Arten zusammenstellen: Zum einen durch eine generelle Anfrage an alle Systeme, wenn er Master Browser wird, und zum anderen durch die Meldung, die er von jedem neu gestarteten Rechner erhält: Direkt nach dem Neustart schickt der neue Rechner einen ``Service Announcement Broadcast''. Diese Mitteilung wird anfangs jede Minute wiederholt; mit der Zeit wird das Intervall zwischen den Meldungen bis zu 12 Minuten verlängert. In einem Netzwerk mit mehreren Domänen tauschen die Master Browser zudem ihre Browse-Listen untereinander aus. Der Master Browser erfährt vom Verlust einer Ressource erst durch das wiederholte Ausbleiben des Service Announcements. Er wartet insgesamt 3 Perioden zu 12 Minuten, bevor er die Ressourcen aus seiner Browse-Liste löscht. Wenn man dann noch berücksichtigt, daß er seine Daten nur alle 15 Minuten an die Backup browser übermittelt, so wird einsichtig, warum eine Ressource auch lange nach deren Wegfall noch in der Liste vorhanden sein kann.

Browser-Wahl

Die Rolle des Master Browsers wird nicht vom Administrator vergeben, sondern in einem Wahlvorgang dynamisch festgelegt. Der Wahlvorgang wird dadurch ausgelöst, daß ein Rechner auf eine Anfrage an den Master Browser keine Antwort erhält. Er sendet dann einen Broadcast mit der Aufforderung zu Wahl, und nominiert sich als den zukünftigen Master Browser. Jedes System, das diese Nachricht erhält, prüft die darin angegebene Qualifikation mit seiner eigenen Qualifikation. Ist die Qualifikation besser, so nimmt das System selbst an der Wahl teil. Andernfalls versucht das System zu entscheiden, wer die Wahl gewonnen hat. Die Qualifikation leitet sich teilweise aus dem benutzen Betriebssystem ab: Ein Windows NT Server ist für die Aufgabe des Master Browsers besser qualifiziert als eine Windows NT Workstation --- die wiederum Windows for Workgroups Clients überlegen ist. Die besten Qualifikationen hat im allgemeinen der PDC einer Domain. Ist er für die Wahl nicht verfügbar und sind mehrere gleich qualifizierte Kandidaten verfügbar, so entscheiden Faktoren wie Aktualität der vorgehaltenen Browse-List, Uptime und letzendlich der Systemname. Wenn ein Browser die Nachricht erhält, daß er die Wahl gewonnen, dann wartet er eine gewisse Zeitspanne ab, bevor er eine erneuete Wahlaufforderung sendet. Wird diese Wahl nicht durch eine besser qualifizierte Wahlaufforderung angefochten, so wird der Browser zum Master Browser. Falls doch eine weitere Nachricht eintrifft, so erklärt sich der verlierende Browser zum backup Browser.

Windows NT und TCP/IP

Wie beim Überblick über die Komponenten der Netzwerkarchitektur von Windows NT gezeigt wurde, ist TCP/IP nur eines von vielen möglichen Transportprotokollen für ein Windows-Netzwerk. Es ist jedoch vor allen Dingen auch der gemeinsame Nenner, über den sich Windows NT-Rechner einfach in ein heterogenes Netzwerk integrieren lassen. Das Kommunikationsmedium der Rechner untereinander ist dann NetBIOS über TCP/IP (NBT). TCP/IP basierende Clients wie FTP und Telnet sind für alle NT-Systeme verfügbar, während Server-Dienste wie ftpd, telnetd oder lprd nur mit NTAS geliefert werden. Zwei für Windows spezifische Dienste sind das ``Dynamic Host Configuration Protocol'' (DHCP) und der ``Windows Internet Name Server'', die im folgenden etwas genauer erläutert werden.

Das Dynamic Host Configuration Protocol

Zur Vereinfachung der TCP/IP-Konfiguration von NT-Rechnern kann deren IP-Adresse dynamisch während des Bootvorgangs vom DHCP-Server konfiguriert werden. Der Vorteil vor allem für tragbare Rechner liegt auf der Hand: Der Rechner kann ohne Neukonfiguration von einem Subnetz entfernt und an ein anderes angeschlossen werden, da er ja jedesmal eine passende neue Konfiguration vom DHCP-Server bezieht. DHCP ist eine Erweiterung des BOOTP-Protokolls und ist in den RFC 1533, 1534, 1541 und 1542 beschrieben. Eine sinnvolle Anwendung für den Einsatz von DHCP wäre eine Firma, in deren Netzwerk nicht mehr genügend Netzwerknummern zur Verfügung stehen, um jedem Rechner eine feste IP-Adresse zuzuordnen. Wenn die freien Adressen per DHCP vergeben werden, kann das Kontingent optimal ausgenutzt werden.

DHCP beim Client

Die Arbeitsweise von DHCP läßt sich am besten an dem in Abbildung 3.1 dargestellten Zustandsdiagramm erklären: Beim Systemstart ist der DHCP-Client zunächst im Zustand ``Initialisieren'', wo er per Broadcast eine ``Discover-Message'' auf das lokale Netzwerk schickt und in den Zustand ``Auswählen'' übergeht. Jeder DHCP-Server, der die ``Discover-Message'' erhalten hat, schickt dem Client eine ``Offer-Message'' zurück, die eine Konfiguration enthält. Der Client wählt nun eine dieser Konfigurationen aus und geht in den Zustand ``Anfordern'', in welchem er per ``Request-Message'' den Server spezifiziert, dessen Konfiguration er benutzen möchte. Der Server schickt daraufhin eine ``Acknowledge-Nachricht'', die noch einmal die angebotene Konfiguration sowie eine Nutzungsberechtigung oder ``Lease'' enthält. Der Client geht dann in den Zustand ``Gebunden'' über. Er kann jetzt am TCP/IP-Netzwerk teilnehmen und seinen Systemstart beenden. Wenn der Client eine eigene Festplatte hat, kann er sich diese Konfiguration merken und bei späteren Neustarts innerhalb der Leihfrist der Konfiguration wiederverwenden. Sobald die Lease-Dauer 50% der gesetzten Frist übersteigt, geht der Client in den Zustand ``Erneuern'' über, wo er beim Server eine Verlängerung der Leihfrist anfordert. Im Normalfall wird der Server dieser Anfrage stattgeben. Ist das nicht der Fall, so geht der Client nach 87,5% der Leihfrist in den Zustand ``Neu binden'' über, wo er vom Server eine neue Konfiguration fordert. Scheitert auch dies, weil z.B. der Server offline ist, so fällt der Rechner in den Zustand ``Initialisieren'' zurück, wo er per ``Discover-Message'' einen neuen Server sucht. Neben den Schnittstellen-Parametern wie IP-Adresse, Netzmaske und Broadcast-Adresse können per DHCP auch weitere Parameter übergeben werden. In NT-Netzwerken mit DHCP ist es beispielsweise üblich, dem Client auch die Adresse seines zuständigen ``Windows Internet Name Service'' (WINS) mitzugeben. Allerdings unterstützen bei Windows NT weder DHCP-Server noch Client die sogenannten ``Message Overlays'', mit denen größere Blöcke an Konfigurationsdaten übers Netz übertragen werden. Wenn ein DHCP-Client unter NT von einem Nicht-NT DHCP-Server konfiguriert werden soll, muß darauf geachtet werden, daß die wichtigsten Konfigurationsdaten als erste übertragen werden.

Namensauflösung in Windows-Netzwerken

Bei TCP/IP wird ein Rechner eindeutig durch seine IP-Adresse identifiziert. Anwender ziehen den schwer zu merkenden Adressen symbolische Namen vor. Deswegen braucht man unter TCP/IP einen Mechanismus, um Namen in IP-Adressen umzusetzen. Windows NT bietet dazu die folgenden Methoden an:

Namensauflösung per Broadcast

Windows-Rechner können die ``Broadcast Name Resolution'' benutzen, was als NBt-Modus ``b-Node'' bezeichnet wird. Dieses Verfahren benutzt IP-Broadcasts zur Registrierung und zum Auffinden von Rechnern. Beim Systemstart registriert ein startender Rechner seinen Namen auf dem Netzwerk, indem er ihn bekannt gibt --- wenn dieser Name schon benutzt wird, so muß der Rechner mit diesem Namen darauf sofort reagieren. Mit der gleichen Methode wird auch der Rechnername zur Adresse aufgelöst. Das ``b-Node''-Verfahren hat zwei wesentliche Probleme:

Windows Internet Name Service

Ein Windows-Rechner kann WINS benutzen, wenn einer oder mehrere WINS-Server verfügbar sind. Diese Server halten eine dynamisch generierte Datenbank bereit, in denen Namen-Adressen-Tupel gespeichert werden. Beim Systemstart registrieren sich Rechner statt per Broadcast direkt am WINS-Server, so daß der WINS-Server zu der Instanz wird, die Kollisionen erkennt und Namen auflöst. Die Namensauflösung per WINS wird unter NetBIOS über TCP/IP (NBT) als ``p-Node'' Modus bezeichnet. Die Nachteile des ``p-Node''-Verfahrens sind: WINS kann auch zusammen mit der Namensauflösung per Broadcast benutzt werden, wenn andere Methoden nicht adäquat sind. Beim ``m-Node''-Verfahren werden zuerst Broadcasts benutzt, um die Ressource zu finden und dann auf ``p-Node''-Betreib umgeschaltet. Man verspricht sich hierbei einen Performance-Gewinn, da man davon ausgeht, daß sich eine gewünschte Ressource am ehesten im lokalen Netzwerk befindet. Zwar erzeugt dieses Verfahren auch viel Broadcast-Traffic, aber dafür ist es möglich, Router zu überbrücken. Sollte der WINS-Server ausfallen, so sind immer noch die Ressourcen im lokalen Netzwerk erreichbar. Das derzeit im Draft-Stadium befindliche ``h-Node''-Verfahren benutzt zur Namensauflösung zunächst den WINS-Server und erst dann Broadcasts. Die ist das Verfahren der Wahl, das normalerweise auch von den Implementationen von Microsoft TCP/IP genutzt wird, wenn der Benutzer bei dre Konfiguration von TCP/IP einen WINS-Server angibt.

Domain Name Service

Der Domain Name Service (DNS) ist eine verteilte Datenbank zur Namensauflösung im Internet. Rechner im lokalen Netzwerk können einen lokalen DNS-Server jedoch auch zur Namensauflösung benutzen. DNS ist hierfür allerdings nicht unbedingt flexibel genug, denn die Bindung eines Namens an eine Adresse ist statisch, so daß sich die Namensauflösung per DNS mit der Rechnerkonfiguration per DHCP beißt. Will man partout DNS und DHCP zusammen benutzen, dann muß es zumindest für die Hosts, die per DNS registriert sind, feste Leases geben, die nicht ablaufen.

Namensauflösung per LMHOSTS-Datei

Bei diesem Verfahren besitzt jeder Rechner seine eigene Liste mit Namen und zugehörigen IP-Adressen, die er zur Namensauflösung benutzt. Da der Aufwand für die Pflege einer solchen Datei mit steigender Zahl der Hosts immer mehr zunimmt, ist dieses Verfahren jedoch nur in kleinen Netzwerken sinnvoll.

Remote Access Services

Windows NT unterstützt mit seinen Remote Access Service (RAS) die Anbindung von mobilen Rechnern oder entfernten Netzwerken über Wählverbindungen. Der RAS-Client zur Einwahl ist sowohl auf NT Workstation als auch auf NT Advanced Server verfügbar, während die Server-Funktionalität nur im Server-Betriebssystem enthalten ist. RAS unterstützt für seine Verbindungen das Standardprotokoll PPP, mit dem Verbindungen für die Protokollstacks TCP/IP, IPX/SPX und NetBEUI heregestellt werden. Da es sich bei PPP prinzipiell um einen auf Schicht 2 des ISO/OSI Sieben-Schichten-Modells angesiedeltes Protokoll handelt, das prinzipiell nur Frames überträgt, kann es auch mehrere dieser Protokolle gleichzeitig unterstützen. Für RAS-Clients unter Windows NT ist als Alternative auch das ältere SLIP als Kommunikationskanal für TCP/IP verfügbar --- allerdings bietet NT Server keine entsprechende Server-Komponente, die eine SLIP-Einwahl zulassen würde.

Authentisierung

Das PPP-Protokoll handelt beim Verbindungsaufbau zwischen Client und Server zunächst das Framing aus. Ist diese Kommunikationsgrundlage hergestellt, authentiziert sich der Client beim Server. Dazu wird ein Authentisierungsverfahren zwischen den beiden ausgehandelt. Der Server verlangt vom Client hierzu eine Authentisierung unter dem Schutz des besten beiden bekannten Verschlüsselungsverfahrens.

NetBIOS-Gateway

Eines der leistungsfähigsten Features des Windows NT RAS Servers ist der NetBIOS-Gateway: Wenn der Client-Rechner das NetBEUI-Protokoll als Transport benutzt, dann kann der Server bei Bedarf die darüber transportierten Server Message Blocks auf TCP/IP oder IPX/SPX umsetzen, um dem Client an einem Multiprotokoll-Netzwerk Zugriff auf alle verfügbaren Ressourcen zu geben.

Zusammenfassung

Windows NT erfüllt die Ansprüche, die an ein System gestellt werden, das heute in heterogenen Client/Server-Architekturen eingesetzt werden soll: Microsoft hat es mit NT geschafft, die bei den Anwendern beliebte Windows-Oberfläche auf ein vernüftiges Fundament zu setzen.

Literaturverzeichnis

Auswege: Impressum, Haftungsausschluß, Datenschutz, Meine Homepage.
Thomas Bätzler, Thomas@Baetzler.de 
$Id$