Letzte Änderung: 18.3.99 von B. Tritsch, Max Kleiner
Windows NT unterstützt mehrere Protokolle parallel, wobei jedoch nicht alle installiert sein müssen. Auf vielen NT-Rechnern sind typischerweise zwischen einem und drei Protokollen installiert.
Weitere Protokolle lassen sich jederzeit nachinstallieren.
Im folgenden werden die wichtigsten Protokolle für Windows NT im Detail betrachtet.
Auf der OSI Network-Schicht kann man das Internet als eine Sammlung von Subnetzen oder autonomen Systemen betrachten, die miteinander verbunden sind. Der Klebstoff, der alles zusammenhält ist IP, das Internet Protocol.
Grundsätzlich funktioniert die Kommunikation im Internet wie folgt: Das Transport Layer nimmt die Datenströme und bricht sie in Datagramme auf. Theoretisch können Datagramme bis zu 64 kBytes groß sein, in Wirklichkeit sind sie selten größer als 1500 Bytes. Jedes Datagramm wird über das Internet transportiert und dabei möglicherweise sogar noch in kleiner Fragmente zerteilt. Wenn die Bruchstücke dann an ihrem Ziel angelangen, werden sie von der dortigen Network-Schicht wieder zu den originalen Datagrammen zusammengesetzt. Diese werden dann an den Transport Layer weitergereicht, von wo sie dem Eingangsdatenstrom des empfangenden Prozesses zugeleitet werden.
Das IP-Datagramm besteht aus dem Header und dem Datenteil. Der Header unterteilt sich in einen 20 Bytes langen statischen Teil und einen optionalen Teil variabler Länge.
Die Übertragung geschieht in der Big-Endian-Reihenfolge, d.h. von links nach rechts mit dem High-Order-Bit des Versionsfeld als erstes (SPARC ist Big-Endian, Pentium ist Little-Endian). Auf Little-Endian-Maschinen muß die Konversion sowohl beim Sender als auch beim Empfänger in Software durchgeführt werden.
Bewegt man sich nun in das Transport Layer, so besitzt das Internet zwei Hauptprotokolle , wobei das eine verbindungsorientiert (TCP) und das andere verbindungslos (UDP) ist. Hierbei ist UDP grundsätzlich identisch mit IP bis auf einen sehr kleinen Header. TCP (Transmission Control Protocol) wurde speziell dafür entwickelt einen verläßlichen Punkt-zu-Punkt Byte-Strom über ein unzuverläßiges internationales Netzwerk zu ermöglichen. Ein solches Netzwerk unterscheidet sich von einem Intranet, da es unterschiedlich aus Sicht der Topologie, der Bandbreite, der Verzögerungen, der Paketgrößen und vieler anderer Parametern sein kann. TCP wurde so ausgerichtet, um sich dynamisch auf diese Eckdaten einstellen zu können.
TCP wurde zunächst über den RFC 793 definiert. Nach einiger Zeit wurden Fehler und Inkonsistenzien verbessert sowie Erweiterungen spezifiziert (RFCs 1122 und 1323). TCP sorgt im Gegensatz zu IP für die Garantie, daß Pakete korrekt übertragen und in der richtigen Reihenfolge wieder zusammengesetzt wurden.
Die verschiedenen TCP-Services werden dadurch bereitgestellt, daß sowohl Sender als auch Empfänger Kommunikationsendpunkte erzeugen, die Sockets genannt werden. Jeder Socket hat eine Socket-Nummer (Adresse), die aus der IP-Adresse des Rechners und einer lokalen 16-Bit-Zahl (dem Port) besteht. Um einen TCP-Service zu erhalten muß die Verbindung explizit zwischen dem Socket der sendenden und dem Socket der empfangenden Maschine etabliert werden.
Port-Nummern unter 256 werden Well-known Ports genannt und sind für Standard-Services reserviert. Möchte ein Prozeß beispielsweise eine Verbindung zu einem Rechner aufnehmen, um einen Datentransfer über FTP zu starten, so benutzt er den Port 21. Die Liste der Well-known Ports steht im RFC 1700. Die SERVICES-Datei von Windows NT 4.0 (Pfad: %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC) sieht beispielsweise folgendermaßen aus:
echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp qotd 17/tcp quote qotd 17/udp quote chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver rlp 39/udp resource # resource location name 42/tcp nameserver name 42/udp nameserver whois 43/tcp nicname # usually to sri-nic domain 53/tcp nameserver # name-domain server domain 53/udp nameserver nameserver 53/tcp domain # name-domain server nameserver 53/udp domain mtp 57/tcp # deprecated bootp 67/udp # boot program server tftp 69/udp rje 77/tcp netrjs finger 79/tcp link 87/tcp ttylink supdup 95/tcp hostnames 101/tcp hostname # usually from sri-nic iso-tsap 102/tcp dictionary 103/tcp webster x400 103/tcp # ISO Mail x400-snd 104/tcp csnet-ns 105/tcp pop 109/tcp postoffice pop2 109/tcp # Post Office pop3 110/tcp postoffice portmap 111/tcp portmap 111/udp sunrpc 111/tcp sunrpc 111/udp auth 113/tcp authentication sftp 115/tcp path 117/tcp uucp-path 117/tcp nntp 119/tcp usenet # Network News Transfer ntp 123/udp ntpd ntp # network time protocol (exp) nbname 137/udp nbdatagram 138/udp nbsession 139/tcp NeWS 144/tcp news sgmp 153/udp sgmp
Alle TCP-Verbindungen sind Full-Duplex und Punkt-zu-Punkt. Full-Duplex bedeutet, daß der Datenverkehr gleichzeitig in beide Richtungen erfolgen kann. Punkt-zu-Punkt bedeutet, daß jede Verbindung exakt zwei Endpunkte besitzt. TCP unterstützt kein Multicast oder Broadcast.
Jeder Knoten in einem TCP/IP-Netzwerk besitzt eine weltweit eindeutige IP-Adresse. Bei der Kommunikation wird diese Adresse zur Identifikation von Quelle und Ziel eines Datenpakets verwendet. Die Konvention für die IP-Adressen basiert auf einem 32-Bit-Wert, wobei die Darstellung im Dezimalsystem erfolgt. Jeder 8-Bit-Dezimalwert (Oktet) wird durch einen Punkt von seinem Nachbarn getrennt (z.B. 192.44.32.1), wobei die Bezeichnung hierfür Dotted Decimal Notation lautet. Der 32-Bit-Wert kodiert die Netzwerk- und die Host-Nummer der zugrundeliegenden Adresse. Hierbei sind die Netzwerke in verschiedene Klassen eingeteilt, die durch zugehörige Subnetzmasken bestimmt werden (z.B. 255.255.255.0). Jede Subnetzmaske wird verwendet, um den Netzwerk- und den Hostteil der Adresse zu identifizieren.
Die Adreßklassen werden in einem weltweit gültigen Schema von A bis G unterschieden. Nur die ersten drei Klassen A bis C sind für Benutzer bestimmt. Adressen der Klasse D sind für Multi-Casting-Zwecke reserviert und Adressen der Klasse E dienen dem Testbetrieb und zukünftigen Entwicklungen. Der Wert 127 in den ersten Oktets ist für einen Loopback reserviert, d.h. eine Rückkopplung auf sich selbst.
Ein Netzwerk der Klasse A besitzt eine Subnetzmaske, die mindestens 8 Bits lang ist. Die Subnetzmaske für ein Netzwerk der Klasse B ist mindestens 16 Bits lang, die Subnetzmaske für ein Netzwerk der Klasse C mindestens 24 Bits.
|
Klasse |
ID |
Adresse |
Adressraum |
|---|---|---|---|
| A | 1 Bit (0) | 7 Bits (Network) + 24 Bits (Host) | 1.0.0.0 bis 127.255.255.255 |
| B | 2 Bits (10) | 14 Bits (Network) + 16 Bits (Host) | 128.0.0.0 bis 191.255.255.255 |
| C | 3 Bits (110) | 21 Bits (Network) + 8 Bits (Host) | 192.0.0.0 bis 223.255.255.255 |
| D | 4 Bits (1110) | 28 Bits Multicast-Adresse | 224.0.0.0 bis 239.255.255.255 |
| E | 5 Bits (11110) | 27 Bits Reserviert für die Zukunft | 240.0.0.0 bis 247.255.255.255 |
Tabelle 3.1: IP-Adressenformat
Neben den Richtlinien für den Zugriff auf einzelne Hosts gibt es zusätzlich spezielle Adressierungsmethoden in einem Netzwerk. Sie betreffen insbesondere den Zugriff auf sich selbst und auf Hosts im eigenen Netzwerksegment sowie Rundrufe (Broadcasts) auf alle Rechner einer bestimmten Netzwerkgruppe.
Das Netzwerk einer bestimmten Klasse kann für interne Unterteilungszwecke (weniger Belastung des Backbones, Aufteilung in Abteilungen) in Subnetze eingeteilt werden. Die Rechner innerhalb des Subnetzes werden dabei direkt angesprochen, alle anderen über ein Default Gateway d.h. typischerweise einen Router. Eine Subnetzmaske für beispielsweise 256 Rechner lautet 255.255.255.0. Diese Maske wird über bool'sche Operationen mit der Rechneradresse verknüpft und gibt darüber Auskunft, ob ein anderer Rechner zum selben Subnetz gehört oder nicht.
Die Einstellung der IP-Adresse, der Netzwerkmaske und des Gateways erfolgt über den "Systemsteuerung"-Ordner: Start - Einstellungen - Netzwerk-Icon - Protokolle - TCP/IP-Protokoll - IP-Adresse
Die Tage des heutigen Adreßschemas von IP sind gezählt, denn die gültigen Adressen werden durch die enorme Ausbreitung des Internets knapp. Sollen jedoch wie geplant Millionen neuer Maschinen in das Internet aufgenommen werden, muß dieser Zustand verbessert werden. Seit 1990 wurde daher die Arbeit an einer neuen IP-Konvention begonnen (IP Version 6, genannt IPv6).
Das historische von Microsoft und IBM in ihren Netzwerkbetriebssystemen eingesetzte Standardprotokoll ist NetBEUI (NetBIOS Enhanced User Interface). Es wird bis heute von Windows NT, Windows 95 und auch von OS/2 unterstützt, ist jedoch nicht routing-fähig. Andererseits ist es sehr einfach zu installieren und zu verwalten.
Ausgangspunkt für die Entwicklung von NetBEUI war die NetBIOS-Schnittstelle. (Network Basic Input/Output System). Sie wurde schon zu Urzeiten der MS-DOS-Netzwerke von Microsoft entwickelt und besteht aus weniger als 20 einfachen Befehlen, die für den Datenaustausch sorgen. Insbesondere werden über NetBIOS die Anfrage- und Antwortfunktionalitäten zwischen Client- und Server-Komponenten realisiert. Dies gilt auch noch für eine Reihe von Software-Komponenten unter Windows NT.
NetBIOS-Anwendungen sind nicht auf das NetBEUI-Protokoll angewiesen, sondern können auch über TCP/IP oder IPX betrieben werden.
Ab Windows NT 3.5x wurde zusätzlich zum NetBEUI-Protokoll das NWLink-Protokoll eingeführt, ein NetWare-kompatibles Protokoll. Es ist kompatibel zu Novells SPX/IPX und kann in einem Netzwerk genauso wie NetBEUI oder TCP/IP den Transport der Daten übernehmen. Mit dem NWLink-Protokoll kann man sich mit einem Windows NT-Rechner direkt als Client an einem Novell-Netzwerk anmelden. Ressourcen dieses Netzwerks (Dateien, Peripherie-Geräte) kann man jedoch erst dann verwenden, wenn man den NetWare-Gateway-Service eingerichtet hat.
IPX/SPX (Internetwork Paket Exchange/ Sequenced Paket Exchange) ist das Protokoll der in LANs weit verbreiteten NetWare-Netze. Dieses Protokoll wurde erst mit der Windows NT Version 3.5 in den NetWare-Kompatiblitätsdiensten verfügbar. Jetzt verliert es langsam wieder an Bedeutung, da Novell ähnlich wie Microsoft den konsequenten Umstieg auf das TCP/IP-Protokoll durchführt.
Das DLC-Protokoll (Data Link Control) lehnt sich an einen Industriestandard (IEEE 802.2) an und wurde nicht spezielle für die Netzwerkverbindung von PCs entwickelt. Es ist jedoch möglich über DLC direkt auf die zweite OSI-Schicht (Data Link Layer) zuzugreifen. Der Redirector von Windows NT unterstützt DLC dagegen nicht, weshalb es für die Client/Server-Kommunikation zwischen NT-Rechnern nicht eingesetzt werden kann.
DLC dient daher primär zur Verständigung zwischen zwischen Windows NT und Mainframe-Rechnern sowie besonderen Komponenten wie JetDirect-Karten von HP oder MarkVision-Karten von Lexmark. DLC muß jedoch nur auf den Druck-Servern installiert sein, die die entsprechende Drucker-Hardware direkt ansprechen.
Das AppleTalk-Protokoll wird auf Macintosh-Computern zur Kommunikation verwendet. Ein spezieller Dienst erlaubt die Konfiguration von Windows NT Servern in einer Weise, daß mit Macintosh-Computern Ressourcen wie Festplatten oder Drucker geteilt werden können. Für Macintosh-Clients stellt sich die Situation dar, als würden sie Verbindung zu einem AppleShare-Server aufnehmen. Die Anzahl der potentiellen Verbindungen von Apple-Clients ist unbegrenzt und wird nur von den 15 Kbytes benötigten Speicherplatz pro Sitzung beschränkt.
Der Windows NT Service für Macintosh ist kompatibel zu AFP 2.1, unterstützt jedoch auch AFP 2.0-Clients. Dies bedeutet,daß Clients ab der MacOS-Version 6.0.7 eingesetzt werden können. Hierbei werden alle Dateiattribute einschließlich den Datenzweigen (Resource Fork) und 32-Bit-Verzeichnis-IDs unterstützt. Die Druckfunktionalitäten beinhalten die vollständige Unterstützung von PostScript. Einzig die Anzeige des Microsoft-Logos auf einem eingebundenen Macintosh-Desktops wird von manchen Apple-Benutzern als störend empfunden.
In einer verteilten Umgebung müssen die Daten zwischen Client- und Server-Anwendungen direktional ausgetauscht werden. Hierfür gibt es unter Windows NT sieben Möglichkeiten: Named Pipes, Mailslots, NetBIOS, Windows Sockets, RPCs, NetDDE, SMBs und DCOM.
Named Pipes und Mailslots wurden ursprünglich als Treiber für Dateisysteme entwickelt und stammen noch aus der OS/2-Welt. Eine Pipe verbindet zwei Prozesse miteinander, so daß die Ausgabe des einen als Eingabe des zweiten dienen kann. Named Pipes sind verbindungsorientiert und basieren auf OS/2-API-Aufrufen. Mailslots sind Bestandteil der OS/2-LAN-Manager-Implementierung und erlauben die verbindungslose Übertragungen von Rundsendungen (Broadcasts). Named Pipes und Mailslots können sowohl von lokalen Prozessen als auch über den Redirector für entfernte Kommunikation eingesetzt werden.
Die NetBIOS-Schnittstelle wird schon seit Anfang der achtziger Jahre zur Entwicklung von verteilten Anwendungen verwendet. Die Kommunikation von NetBIOS-Applikationen kann über verschiedene Protokolle erfolgen:
Viele Anwendungen und Dienste, die für den Betrieb einer Windows NT-Umgebung benötigt werden, basieren auf der NetBIOS-Schnittstelle. Wird NetBIOS über TCP/IP betrieben, verwendet es die TCP- und UDP-Ports von 137 bis 139.
Die Windows Socket-Schnittstelle erlaubt die Kommunikation über Protokolle mit unterschiedlichen Adressierungssystemen. Momentan werden TCP/IP sowie NWLink (IPX/SPX) von den Windows Sockets unterstützt. Ursprünglich wurden sie von den Berkeley Sockets abgeleitet, einer Standardschnittstelle zur Entwicklung von Client/Server-Anwendungen unter UNIX und vieler anderer Plattformen.
Das Konzept der Remote Procedure Calls (RPCs) wurde von Sun Microsystems entwickelt, um Prozesse so auf einem entfernten Rechner aufzurufen, als würden sie lokal ausgeführt werden. Die Entwickler sollten sich nicht um Details für die Netzwerkkommunikation kümmern müssen, so wie dies z.B. bei den Windows Sockets notwendig ist. RPCs setzen daher Methoden wie Named Pipes, NetBIOS oder Windows Sockets als Basis ein und kapseln die eigentliche Kommunikation.
Bei Network Dynamic Data Exchange (NetDDE) handelt es sich um eine Erweiterung des DDE-Mechanismus‘ zum Austausch von Daten zwischen Windows-Anwendungen. Um NetDDE verwenden zu können, muß ein NetBIOS-kompotibles Netzwerk eingesetzt werden.
Zur Weiterleitung von bestimmten Informationen zwischen Computern werden Server Message Blocks (SMBs) eingesetzt. Für die Verteilung von SMBs auf entfernte Geräte und den lokalen Rechner spielt der Redirector eine zentrale Rolle. Er sorgt für die reibungslose Interaktion zwischen den verschiedenen Versionen der Netzwerkprodukte von Microsoft und anderer Hersteller. Die Funktionalitäten der SMBs umfassen insbesondere Sitzungssteuerung, Dateizugriffe, Druckerkontrolle und Nachrichtenmeldungen.
Die Konzepte des Distributed Common Object Model (DCOM) spielen eine wachsende Bedeutung unter Windows NT und einer Reihe von weiteren Plattformen. Mit DCOM lassen sich komplexe Multi-Tier-Modelle über Objektkommunikation realisieren.