Übersicht - DSpace at ICSY
Werbung
Windows NT Netzwerkstruktur Studienarbeit Thema: Protokolltreiber-Architektur von Windows NT Autor: Sebastian Sehr Betreuer: Dipl.-Informatiker Bernd Reuther Kurs: TIT 97 A Fachrichtung: Projektengineering Studienarbeit von Sebastian Sehr Seite 1 von 23 Windows NT Netzwerkstruktur ERKLÄRUNG Hiermit erkläre ich, daß ich die vorliegende Arbeit selbständig und ohne fremde Hilfe verfaßt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Insbesondere versichere ich, daß ich alle wörtlichen und sinngemäßen Übernahmen aus anderen Werken als solche kenntlich gemacht habe. 76646 Bruchsal, __________________________ Sebastian Sehr Studienarbeit von Sebastian Sehr Seite 2 von 23 Windows NT Netzwerkstruktur INHALTSVERZEICHNIS 1 MOTIVATION ............................................................................................. 4 1.1 WAS IST VIAA? .............................................................................................................. 4 1.2 EINLEITUNG ............................................................................................... 5 2 ÜBERSICHT................................................................................................. 5 3 TREIBER-TYPEN ....................................................................................... 8 3.1 NDIS............................................................................................................................... 8 3.1.1 Miniport Driver ...................................................................................................... 9 3.1.2 Intermediate Driver .............................................................................................. 10 3.1.3 Upper Level Protocol Driver ................................................................................ 10 3.2 ANDERE AUSGABESCHNITTSTELLEN ............................................................................. 10 3.3 PROTOKOLL-TREIBER.................................................................................................... 10 3.3.1 Detaillierter Aufbau eines NDIS-Protokoll-Treiber ............................................. 11 4 SCHNITTSTELLEN.................................................................................. 11 4.1 NDIS (NETWORK DRIVER INTERFACE SPECIFICATION) ................................................ 11 4.2 TDI (TANSPORT DRIVER INTERFACE) ........................................................................... 12 4.3 SPI (SERVICE PROVIDER INTERFACE) ........................................................................... 14 5 ZUGRIFF AUF DIE TRANSPORT-PROVIDERS ................................ 15 5.1 ANWENDUNGEN FÜR DIE WINSOCK ............................................................................... 15 5.2 ANWENDUNGENZUGRIFF ÜBER DEN REDIRECTOR ......................................................... 16 6 REGISTRIERUNG .................................................................................... 17 6.1 NDIS PROTOCOL DRIVER ............................................................................................. 17 6.1.1 Öffnen eines unterliegenden Adapters ................................................................. 17 7 RÉSUMEÉ .................................................................................................. 18 8 ABBILDUNGSVERZEICHNIS ............................................................... 18 9 ABKÜRZUNGSVERZEICHNIS .............................................................. 19 10 QUELLENANGABE ................................................................................. 19 10.1 REFERENZIERTE QUELLEN DIESER ARBEIT ................................................................ 19 10.2 WEITERE QUELLENANGABEN .................................................................................... 20 10.2.1 Grundlagen und Übersicht für die Programmierung ............................................ 20 10.2.2 Winsock................................................................................................................ 21 10.3 WEITERE INTERNET LINKS ........................................................................................ 21 11 ANHANG A ................................................................................................ 22 11.1 PROTOCOLXXX-FUNCTIONS ...................................................................................... 22 Studienarbeit von Sebastian Sehr Seite 3 von 23 Windows NT Netzwerkstruktur 1 1.1 Motivation Was ist ViAA? ViAA ist ein Projekt der Universität Kaiserslautern und steht für Virtuelle ATM API. Ziel dieses Projektes ist es, neuen multimedialen Anwendungen eine nahtlose ende zu ende Kommunikation zu ermöglichen. Das besondere dabei, - diesen Anwendungen sollen die ATM Quality-of-Service (QoS) Merkmale bereitgestellt werden, obwohl diese über keinen direkten ATM Zugang verfügen. In den meisten Fällen sind Endsysteme dediziert über nicht QoS fähiges Ethernet angeschlossen. Die QoS fähige ATM Technik steht oft erst im Backbone bzw. WAN Bereich zur Verfügung. Die Abbildung 1 verdeutlicht die geschilderte Situation. Das Projekt ViAA bietet hier die Möglichkeit den QoS des Backbone/WAN zu steuern und zu nutzen. Abbildung 1:ViAA Szenario1 Voraussetzung hierfür ist, das die Ethernetstrecke zum Endgerät über ausreichende Bandbreite verfügt und somit auf dieser Strecke keine Ressourcenreservierung notwendig ist. Im Backbone bzw. im WAN Bereich ist jedoch eine Ressourcenreservierung zur Aufrechterhaltung bestimmter Qualitätsansprüche wünschenswert, weil sich die Anwendungen hier die verfügbare und teure Bandbreite mit vielen anderen Anwendungen teilen müssen. Die ATM Funktionalität wird für Applikationen über eine virtuelle ATM API (API = Application Programming Interface) basierend auf der Ethernet Hardware im Endsystem angeboten. Die Umsetzung der QoS Parameter erfolgt am ersten bzw. letzten EdgeDevice der ATM Backbone/WAN Verbindung. Demzufolge sind nur solche Anwendungen betroffen die auf eine solche API aufsetzen und QoS-Parameter setzen können. TCP/IP basierte Anwendungen bleiben hiervon unberührt.“ Die Umsetzung des ViAA-Konzepts soll für die Anwendung transparent bleiben, d.h. die Anwendung erfährt nicht, welches Protokoll benutzt wird, um ihre Daten zu versenden. Das ViAA-Konzept realisiert der ViAA-Treiber, der unter anderem dafür sorgt, daß die QoS ATM Merkmale, die im Backbone bzw. WAN Bereich genutzt werden, in die Ethernetframes eingebunden und versendet werden. Dieser Treiber soll zudem einen geringst möglichen Overhead haben und braucht nicht routingfähig zu sein, was bedeutet, das die Adressenumsetzung ohne IP erfolgt. 1 Quelle Abbildung: Universität Kaiserslautern Studienarbeit von Sebastian Sehr Seite 4 von 23 Windows NT Netzwerkstruktur In dieser Arbeit werden die technischen Anforderungen und Rahmenbedingungen für die Erstellung eines solchen Treibermoduls erarbeitet. Dazu werden die benötigten Schnittstellen und das Zusammenspiel der dazugehörigen Treiber erklärt. Dabei wird auch der Datenfluß von der Applikation bis zur Netzwerkkarte dargestellt. Weiterhin werden alle Notwendigen Schritte für die Programmierung eines solchen Treibermoduls beschrieben. 1.2 Einleitung Die für Windows NT herausgearbeiteten Ergebnisse gelten auch für die Microsoft Betriebssysteme Windows 98 und Windows 2000. Dies gelten jedoch nur für den Aufbau, nicht aber für Algorithmen der Treiber. Für diese Arbeit wird vorrausgesetzt, das Grundlagenkenntnisse im Bereich Rechnernetze vorhanden sind. Der Leser sollte zum Beispiel das ISO/OSI-Referenzmodell kennen. Auf diesem Wege möchte ich mich bei Herrn Bernd Reuther, Herrn Michael Schneider und Herrn Karl-Heinz Waldmann bedanken, die mir für Verständnisfragen immer offen gegenüber standen und ihr Wissen gerne preis gegeben haben. 2 Übersicht Dieses Kapitel gibt einen Einblick in den Aufbau von Windows NT und ordnet die für das ViAA-Projekt wichtigen Schittstellen ein. Es beschriebt den prinzipiellen Aufbau der Netzwerk-Treiberschichten und zeigt Vergleiche, zwischen dem ISO/OSI-Referenz-Modell und Windows NT. Abbildung 2 gibt eine Übersicht, um die Einordnung der benötigten Module zu erleichtern. Die Architektur der Intel-Prozesoren 80386 und höher definieren vier Ebenen, sogenannte Ringe. Diese Architektur soll den Systemcode und die Systemdaten vor überschreiben mit weniger Rechten ausgestatteten Ebenen schützen. Dieser Aufbau wurde auch als IntelSchutzmodell bekannt. Das Microsoft Betriebssystems Windows NT nutzt diesen Aufbau aus den gleichen Gründen. Windows NT definiert zwei dieser Ebenen, den Kernel- und den User-Mode, wobei der Kernel-Mode als Ring0, der User-Mode als Ring3 bezeichnet wird. Ring1 und Ring2 des Intel-Schutzmodell finden keine Verwendung. Der Kernel-Mode ist ein geschützter Bereich, in dem sich auch, die für das ViAA-Projekt wichtigen Netzwerkschnittstellen befinden. Studienarbeit von Sebastian Sehr Seite 5 von 23 Windows NT Netzwerkstruktur Windows Sockets Application Win32 Wnet/WinIne t Applicaton RPC Applicaton NetBIOS Application Applications and User Mode Services Application Interfaces WinInet WNet RPC Windows Sockets NetBIOS Support User Kernel Named Pipes Redirector Server NetBT AFD TDI TCP Packet Classifier ICMP IP Forwarder IP IGMP IP Filtering ARP Packet Traffic Control Packet Queue Packet Queue Packet Queue Scheduler Packet Queue Packet Queue Driver Interfaces NDIS Wrapper NDIS WAN Miniport Wrapper PPTP Asynch X.25 X.25 Frame Relay ATM Ethernet FDDI Token Ring NDIS IIntIn terfac e ISDN Abbildung 2: The Windows 2000 TCP/IP network model 2 Die Abbildung 2 kennzeichnet User- und Kernel-Mode mit den dazugehörigen Modulen. Im Kernel-Mode, zwischen Redirector und dem TCP-Modul liegt die TDI (Transport Driver Interface). Der NDIS (Network Driver Interface Specification) Wrapper (engl. Wrapper = Hülle, Umschlag) abstrahiert die Netzwerkkarte von den darüberliegenden Transport Protokollen, wie TCP/IP und UDP. Der NDIS-Wrapper ist mit den in Windows NT enthaltenen NDISFunktionen realisiert und definiert so eine Schnittstelle (NDIS) zu den Protokoll-Treibern. Über der TDI liegen die Redirectoren und Server, die die Bindeglieder zwischen Kernel- und User- Mode sind. Im User-Mode befinden sich die Windows Sockets, die die Schnittstelle für die Windows Sockets Applikationen bildet. Im Vergleich dazu, gehört die RPC-Schnittstelle im User-Mode zu den RPC Applikationen und die Wnet zu den Win32 Wnet Applikationen usw. Die folgende Abbildung 3 vergleicht das Windows NT Netzwerk-Modell mit dem ISO/OSIReferenz-Modell. „[RL99] Die unteren vier Schichten bilden das Transportsystem, dass die transparente Übermittlung von Daten ermöglicht. Die drei oberen Schichten bilden die Anwendungsdienste, welche die Übermittlung von Informationen realisieren“. QuelleAbbildung: Dave Mac Donald „TCP/IP Implementation Details for Windows 2000 RC1“, White Paper: July 16, 1999 2 Studienarbeit von Sebastian Sehr Seite 6 von 23 Windows NT Netzwerkstruktur Abbildung 3: Windows NT layered architecture 3 Im Vergleich ISO/OSI-Referenz-Modell mit Windows NT, ist in der Übertragungsschicht (Physikal Layer) die Netzwerkkarte NIC (Network Interface Karte) einzuordnen. In der Leitungsschicht (Data Link Layer) befindet sich auf der MAC-Ebene (Media Access Control) der Netzwerkkarten-Treiber (NIC Driver), auf LLC–Ebene (Logical Link Control) der Protokoll-Treiber (Upper Level Protocol Driver), der die NDIS-Funktionen nutzt . Der Protokoll-Treiber muss auch Aufgaben der Netzwerkschicht (Network Layer) und der Transportschicht (Transport Layer) übernehmen. Die Protokoll-Treiber der LLC-Ebene, der Netzwerkschicht und der Transportschicht sind bei Windows NT als Software-Treiber realisiert. Diese Treiber sind als Transport Driver bekannt, oder werden auch als Protocols, Protocol Driver oder Protocol Modules bezeichnet.4 Die Sitzungsschicht (Session Layer), die Darstellungsschicht (Presentation Layer) und die Anwendungsschicht (Application Layer) repräsentieren bei Windows NT die sogenannten Network Providers, Installable File Systems (IFS) Manager und die Redirectoren. Wie das Bild auch zeigt, ist es möglich Tranport-Protokolle in Streams einzubetten. Streams haben neben ihren Vorteilen5 einen große Overhead. Ab der Version 3.51 verzichtet Windows NT für TCP/IP auf Streams, aufgrund des Overheads. Microsoft bezeichnet Treiber, die unterhalb der TDI liegen, im Vergleich mit OSI die Schichten 1 bis 4, als Netzwerk-Treiber (Network Driver). Sie unterteilen sich nochmals in Protokoll-Treiber (z.B. TCP/IP ), die zwischen der NDIS und der TDI liegen und NDISDriver, die als Miniport NIC Driver (NIC= Network Interface Card), Intermediate Driver oder Upper Level Protocol Driver realisiert sein können. 3 Quelle Abbildung: Windows Layered Architecture, MSDN Library July 1999 (Verzeichnis : DDK Documentation, Windows Ressource Kits, Windows NT 4.0 Ressource Kit, Chapter 1: …. 4 [Vgl.] MSDN_ND1 5 [Vgl.] MSDN_RK1 Studienarbeit von Sebastian Sehr Seite 7 von 23 Windows NT Netzwerkstruktur Es ist möglich, gleiche oder unterschiedliche Treiberarten aufeinander aufbauend zu realisieren. Diese bilden dann eine „Treiberkette“. Eine Treiberkette kann intern eigene Schnittstellen haben, die der Programmierer selbst bestimmt (Private Interface). Es ist aber wichtig, das die Funktionen der Schnittstellen von NDIS und TDI an den jeweiligen Außengliedern der Kette genutzt werden, um mit anderen bereits bestehenden Treibern kommunizieren zu können. Netzwerk-Treiber Protokoll-Treiber Private Interface Private Interface upper level Protocol Driver Protokoll-Treiber ... ... TDI NDIS NDIS-Driver: Int ermediat e Driver Miniport Driver Netzwerkkarte (NIC) Abbildung 4:Treiberarten unterhalb der TDI6 Abbildung 4 verdeutlicht, das bestimmte Treiber-Typen, wie zum Beispiel der Inermediate Driver (siehe Kapitel 3.1.2), nicht unbedingt benötigt werden. So sieht man, wenn man den Weg der rechten Pfeile nimmt, dass der Miniport Driver direkt mit dem Upper Level Protocol Driver kommunizieren kann, der wiederum direkt die TDI anbietet. Eine andere Möglichkeit wäre es, wenn der Upper Level Driver nicht die TDI anbietet, sondern über interne Schnittstellen andere Protokoll-Funktionen. Diese können wiederum interne Schnittstellen anbieten, wobei der oberste Protokoll-Treiber die TDI anbieten muss. 3 Treiber-Typen 3.1 NDIS Microsoft stellt mit der NDIS-Schnittstelle definierte Funktionen in der NDIS-Library ndis.sys zur Verfügung. Die NDIS-Treiber nutzen diese Funktionen und kommunizieren über diese miteinander. Durch die NDIS-Funktionen sind Protokoll-Treiber unabhängig von den Netzwerkkartentreibern. 6 Abbildung 4:„Eigene Zeichnung“ ; Quelle: MSDN Library Studienarbeit von Sebastian Sehr Seite 8 von 23 Windows NT Netzwerkstruktur Es gibt drei NDIS Driver Typen (siehe Abbildung 5): 1. Upper Level Protocol Drivers 2. Intermediate Drivers 3. NDIS Miniport Driver (oder Miniport NIC Driver) Abbildung 5: Supported Intermediate Driver Configurations7 Wie die Abbildung 5 zeigt, kommuniziert der NIC-Treiber an der unteren Schnittstelle mit der Netzwerkkarte (NIC= Network Interface Card). An der oberen Schnittstelle bedient er entweder den Intermediate Driver oder direkt den Upper Level Protocol Driver (Transport Driver). In dieser Abbildung ist auch dargestellt, dass der Transport Driver sowie der Intermediate Driver an der unteren Schnittstelle ProtocolXxxx-Funktionen (siehe Kapitel 3.3.1) anbieten. Der NIC Driver, wie auch der Intermediate Driver bieten Miniport XxxxFunktionen an deren oberen Schnittstelle an. 3.1.1 Miniport Driver Der Miniport Driver, auch als Miniport NIC Driver oder einfach nur NIC Driver bezeichnet, ist der Netzwerkkarten-Treiber und wird vom Netzwerkkartenhersteller mit der Netzwerkkarte mitgeliefert. Windows NT enthält auch schon Miniport Driver bekannter Netzwerkkartenhersteller. 7 Quelle Abbildung: NDIS Intermediate Drivers, MSDN Library July 1999 (Verzeichnis : DDK Documentation, Windows NT 4.0 DDK, Network Drivers. Design Guide, Part 3: Intermediate NDIS Drivers and TDI Drivers,… Studienarbeit von Sebastian Sehr Seite 9 von 23 Windows NT Netzwerkstruktur NDIS Miniport Driver haben zwei wichtige Funktionen: 1. Die Netzwerkkarte (NIC) zu managen (senden und empfangen der Daten über die Netzwerkkarte) 2. Über ihm liegende Driver (Intermediate Driver oder Transport Protocol Driver) mit Daten zu beliefern 3.1.2 Intermediate Driver Intermediate Driver liegen zwischen den Miniport Drivers und den Transport und nutzen ebenfalls die NDIS-Funktionen. Eine typische Aufgabe der Intermediate Driver sind Medienumsetzungen. So gibt es zum Beispiel einen WAN Intermediate Driver, der LANProtokolle auf WAN emuliert und diese Daten dann an den Miniport NIC Driver weitergibt. Intermediate Driver kommunizieren zur unteren Schnittstelle mit dem Miniport Driver, nach oben hin mit dem Upper Level Protocol Driver. 3.1.3 Upper Level Protocol Driver Ein Upper Level Protocol Driver bildet die unterste Ebene einer Protokoll-Treiber-Kette und wird oft als Transport-Protokoll-Stack implementiert, wie es bei TCP/IP oder IPX/SPX der Fall ist. Dieser Transport-Protkoll-Treiber bietet seine Dienste mit Hilfe der NDIS-Funktionen einem oder mehreren Intermediate Drivers oder Netzwerkkarten-Treibern an. Nach oben hin kann der NDIS-Treiber die TDI-Funktionen anbieten, oder er bildet die unterste Ebene eine Netzwerkprotokoll-Kette und bietet interne Schnittstellen (Private Interface) zu höher gelegenen Protokoll- Treibern. Ein Upper Level Protocol Driver hat folgende Aufgaben: Daten der Anwendung entgegen nehmen Daten der sendenden Applikation in Pakete packen Pakete an einem niedergelegenen Treiber senden (mit Hilfe der NDIS-Funktionen) Ankommende Datenpakete entgegen nehmen und an die gewünschte Applikation weiterleiten 3.2 Andere Ausgabeschnittstellen Bis hierher wurde verdeutlicht, dass Datenpakete über das Transport-Protokoll an den darunterliegenden Kartentreiber übermittelt werden und von dort aus zu einem entfernten Rechner. Es ist auch möglich diese Daten nicht über die Netzwerkkarte, sondern über die serielle Schnittstelle COM- Port, oder andere Schnittstellen auszugeben. Hierfür wird anstelle des NIC Drivers, der Treiber für den COM- Port aufgerufen (siehe Abbildung 2). 3.3 Protokoll-Treiber Protokoll-Treiber nehmen wie zuvor schon erwähnt im Vergleich mit dem ISO/OSI-ReferenzModell die LLC Ebene, die Schicht 3 und die Schicht 4 war. Es ist möglich in einem Netzwerkprotokoll-Modul Protokoll-Treiber in einer Kette übereinander zu reihen. Hierbei muss das untere Aussenglied der Kette als NDIS Protokoll-Treiber (Upper Level Protocol Driver) realisiert sein. Da alle Windows NT Transport Treiber die TDI anbieten müssen, muss auch das oberer Aussenglied der Protokoll-Treiber-Kette die TDI-Funktionen anbieten. Dazwischen ist es dem Programmierer freigestellt eigene Schnittstellen (Private Interfaces) zu definieren. “[MSDN_ND3] Requiring that all Windows NT transport drivers expose a single common interface (TDI) simplifies the task of developing transport drivers because only that interface needs to be coded.” Studienarbeit von Sebastian Sehr Seite 10 von 23 Windows NT Netzwerkstruktur 3.3.1 Detaillierter Aufbau eines NDIS-Protokoll-Treiber Da für das ViAA-Projekt ein NDIS-Protokoll-Treiber realisiert werden muss, wird dieser Treiber hier nochmals genauer erörtert. Dieser Protokoll Treiber muss als unterer Schnittstelle NDIS-Funktionen nutzen, um Daten zu senden, zu lesen und um Informationen, die die niederen Treiber bereitstellen, aufrecht zu erhalten. Um ein Daten-Paket oder -Pakete zur Netzwerkkarte zu senden, nutzt er NdisSend oder NdisSendPackets. Oder er ruft NdisInitializeEvent auf, um ein Event zu kreieren und synchronisieren. Der Protocol Driver kann auch Betriebssystem spezifische Kernel-Mode Funktionen aufrufen, wie KeInitializeEvent, die auch ein Event kreiert und synchronisiert. Der Protokolltreiber stellt der NDIS eine Anzahl Eintrittspunkte (ProtocolXxx Functions8) zur Verfügung, die von der NDIS aufgerufen werden. Die NDIS nutzt die ProtocolXxx Functions zum Beispiel, um auf eingehende Pakete zu verweisen, den Status niederer Treiber (Miniport Driver) zu kennen, oder um mit dem Protokolltreiber zu kommunizieren. Notwendige ProtocolXxx Funktionen sind: ReceiveHandler ReceiveCompleteHandler TransferCompleteHandler SendCompleteHandler (abeitet mit NdisSend und NdisSendPackets) ResetCompleteHandler (arbeitet mit NdisReset) RequestCompleteHandler (arbeitet mit NdisRequest) StatusHandler StatuscompleteHandler Optionale Funktionen sind: BindAdapterHandler (wird aber empfohlen zu nutzen) UnbindAdapterHandler ReceivePacketHandler Eine Beschreibung der NDIS ProtokollXxxx Funktionen sind im Anhang A beigefügt. Ein NDIS Protokoll-Treiber kann auch als Netzwerkprotokoll-Treiber realisiert werden, der direkt die Funktionen der TDI anbietet. Einen solchen Treiber, der alle protokoll-treiberspezifischen Eigenschaften besitzt, wird auch als monolithischer Protokoll-Treiber bezeichnet. Da für das ViAA-Projekt keine mehrstufige Implementierung notwendig ist und ein geringst möglicher Overhead angestrebt wird, wird ein monolithischer Protokoll-Treiber zu dem gewünschten Ziel führen. 4 Schnittstellen 4.1 NDIS (Network Driver Interface Specification) Die NDIS stellt eine definierte Anzahl von NdisXxxx-Funktionen zur Verfügung, zum Beispiel NdisSend oder NdisSendPackets, wobei die Implementierung-Details verborgen bleiben. Die NDIS gibt es bereits in der Version 5.0. Das bedeutet, das zu älteren Versionen neue Funktionen hinzugekommen sind. Die Version 5.0 unterstützt zum Beispiel auch verbindungsorientierte Netzwerke, wie ATM oder ISDN. Die NDIS-Funktionen befinden sich in der Library ndis.sys. 8 ProtocolXxx-Functions siehe Anhang A Studienarbeit von Sebastian Sehr Seite 11 von 23 Windows NT Netzwerkstruktur Jeder Ndis3.0 kompatible Protokolltreiber, der für Windows NT geschrieben wird, kann über ein Netzwerk mit anderen Rechnern kommunizieren.9 Wie die Abbildung 6 zeigt, bildet die NDIS-Schnittstelle eine Hülle um die NDIS-Treiber. Sie abstrahiert die Netzwerkhardware von den Netzwerktreibern und spezifiziert zudem eine Standardschnittstelle zwischen den verschiedenen Treiberschichten. Dadurch sind die unteren Netzwerkkartentreiber (Miniport NIC Driver), von den höheren Transporttreibern unabhängig. Egal ob der Kartentreiber mit dem Transporttreiber oder dem Betriebssystem kommuniziert oder Hardwareinterrupts auslöst, er benutzt immer dazu die NDIS-Funktionen. Es ist auch möglich mehrere Netzwerkkarten nebeneinander in einem Rechner zu installieren, ohne dass man sich um deren Verwaltung kümmern muss. TDI Abbildung 6: NDIS-Interface10 4.2 TDI (Tansport Driver Interface) Die TDI stellt die einheitliche Schnittstelle für alle Transport-Protokolle dar. Sie findet bereits bei Windows 95 für das TCP/IP-Protokoll Verwendung. Im Gegensatz zur NDIS, gibt es keine TDI-Treiber. Die TDI beschreibt vielmehr die Kommunikation zwischen Netzwerkprotokollen und den darüber liegenden Schichten, wie zum Beispiel Redirectoren und Server. Wie die Abbildung 7 zeigt, liegen über dem TDI-Interface die TDI Clients, wie z.B. der Socket Emulator, oder die Redirectoren und Server. Diese TDI Clients stellen das Bindeglied zwischen Transportprotokoll und Anwendung dar. Da alle Transport-Protokolle (auch Transport Providers genannt) die TDI anbieten, müssen Anwendungen, die eine andere Schittstelle benötigen (zum Beispiel Winsock- oder NetBIOSSchnittstelle), Zugang zur TDI haben. 9 [Vgl.] SDB97 Quelle Abbildung: MSDN Library July 1999 10 Studienarbeit von Sebastian Sehr Seite 12 von 23 Windows NT Netzwerkstruktur Für zwei bekannte Schnittstellen, die Winsock- und die NetBIOS-Schnittstelle enthält Windows NT Emulatoren, die die Daten über die TDI an das benötigte Transport-Protokoll bindet. Abbildung 7: TDI Clients and Transport Providers11 Programme, welche die NetBIOS- oder die Windows Sockets -Schnittstelle benutzen, können nur mit Protokolltreibern kommunizieren, die das TDI unterstützen. Der Grund liegt darin, dass die Winsock nur mit Protokoll-Treibern kommunzieren, die die TDI anbieten. Dies wird in den Kapiteln 4.3 und 5.1 noch genauer erörtert. Die TDI12 beinhaltet: Für Intermediate Driver, eine definierte Anzahl von Windows NT Standard kernelmode Routinen, die über ihr liegende Clients nutzen, um I/O Requests (IRPs) zu senden. Diese können über die Support Routinen Zw..File -Routinen und/oder IoCallDriver aufgerufen werden. Callback Routinen, die jeder TDI Client nutzen kann, um Meldungen vom unterliegenden Tranport Treiber zu bekommen, sollten diese anstehen. TdiXxx-Funktionen, über die Tranport Driver und TDI Clients kommunizieren. TdiBuildXxxx Macros und Funktionen, die TDI Clients nutzen, um Anfragen an die Tranport Protkolle zu senden. 11 Abbildung Quelle: The Transport Driver Interface, MSDN Library July 1999 (Verzeichnis : DDK Documentation, Windows NT 4.0 DDK, Network Drivers, Design Guide, Part 3: Intermediate NDIS Driver and TDI Drivers, TDI Drivers and their Clients 12 [Vgl.] MSDN_ND5 Studienarbeit von Sebastian Sehr Seite 13 von 23 Windows NT Netzwerkstruktur 4.3 SPI (Service Provider Interface) Was von der Anwendungssicht aus die API (Application Programmer Interface) für die Winsock ist, ist von den Service Providern aus die SPI. Sie bietet wie die API definierte Funktionen und liegt im User-Mode (Ring3). Zu fast jeder API-Funktion gibt es eine entsprechende SPI-Funktion. Die Abbildung 8 zeigt den Zusammenhang zwischen API, SPI und den TransportProtokollen. Als Base Protocol werden Transport-Protkolle bezeichnet, die fähig sind eine Netzwerk-Verbindung einzugehen und somit alleine stehen können. Wie TCP und SPX solche Base Protocol sind, wird auch der ViAA-Treiber, als NDIS Upper Level Protocol Driver implementiert, ein Base Protocol sein. Dieses Base Protocol kann direkt über die SPI mit der Winsock kommunizieren oder es bauen Layered Protocols auf ihm auf. Ein Layered Protocol, auch als Service Provider bezeichnet, hat die Eigenschaft, dass es alleine keine Vollständige Kommunikation aufbauen kann. Security Manager werden zum Beispiel als Layered Protocol realisiert. Es ist möglich mehrere Layered Protocols in eine Kette übereinander zu schichten, wobei das oberste Layered Protocol der Kette mit der Winsock kommuniziert. Es ist möglich einen Layered Protocol zu programmieren und diesen in eine bereits bestehende Transport-Kette einzubetten. Die Protokoll-Reihenfolge steht in der WSAProtocol_INFOW, wo auch das „neue“ Layered Protcoll registriert werden muss. Die Protokolle sind als DLLs realisiert, die erst beim Aufruf durch die Anwendung in den Speicher geladen werden. Neuere Bezeichnungen werden statt xxxx.dll als xxxx.WSP bezeichnet, wobei dies keinen Einfluss auf die Funktion des Service Provider hat. Abbildung 8: Service Provider Interface Anmerkung: Layered Protocols werden auch als Layered Service Provider oder als Transport Service Provider bezeichnet. Der Winsock- Emulator ist zum Beispiel ein solcher Service Provider. Base Protocols werden als Base Transport Service Provider oder einfach nur als Transport Service Provider bezeichnet. Wichtig bleibt: ein Service Provider, der im Stande ist ein remote Verbindung einzugehen, ist ein Base Protocol. Weitere Informationen sind unter MSDN_SPI zu finden. Studienarbeit von Sebastian Sehr Seite 14 von 23 Windows NT Netzwerkstruktur 5 Zugriff auf die Transport-Providers 5.1 Anwendungen für die Winsock Abbildung 9: Windows Sockets Helper DLL Architecture13 Möchte eine Anwendung über die Winsock Daten versenden, wird der angeforderte Transport Service mit Hilfe des Socket Service Provider Msafd.dll gebunden. Die Msafd.dll ist bereits in Windows NT enthalten. Um diese Bindung einzugehen, wird für jeden Transport Provider, eine eigene Socket-HelperDLL benötigt. Für TCP/IP heißt sie WSHTCPIP.DLL. Wird ein Transport Protocol Driver mit der dazugehörigen Helper-DLL (WSH DLL) installiert wird, wird das Netzwerk Setup automatisch Msafd.Dll als Service Provider für die WSH DLL konfigurieren. Manche Winsock Sockets Funktionen benötigen nicht die WSH DLL. Sendende und ankommende Daten kommunizieren zum Beispiel direkt über die Msafd.dll mit dem Transport Protocol, wenn die Verbindung erst einmal besteht. Möchte man den ViAA-Treiber für die Winsock zugänglich machen, wird neben dem ViAATransport Treiber noch eine Helper-DLL benötigt, die zum Beispiel WSHViAA.Dll heißen könnte. Die Helper Dlls sind in MSDN_ND7 beschrieben. 13 Quelle Abbildung MSDN Library July 1999 Studienarbeit von Sebastian Sehr Seite 15 von 23 Windows NT Netzwerkstruktur 5.2 Anwendungenzugriff über den Redirector Da Windows NT Workstations Server-, wie auch Client-Funktionen übernehmen können, enthält Windows NT zum Datenaustausch zwei Module, Server und Redirectoren. Die Server, so wie die Redirectoren gehören zur Gruppe der TDI-Clients. Über den Redirector gelangen die Daten an den Transport Provider, in diesem speziellen Fall an den ViAATreiber. Applikationen, die sich über den Redirektoren und Server befinden, liegen im User-Mode. Wie auch bei allen anderen Treiberschichten der Windows NT Architektur, existiert eine einheitliche Schnittstelle, um den Zugang zu den Netzwerk-Ressourcen zugänglich zu machen, die für alle installierten Redirektoren unabhängig ist. Netzwerk Ressourcen sind über zwei Komponenten möglich; den Multiple Universal Naming Convention Provider (MUP) und den Multi-Provider Router (MPR)14. Soetwas muß man nicht zitieren, bitte in eigenen Worten wiedergeben. Da verschiedene Netzwerk-Anbieter, verschiedene Schnittstellen zur Kommunikation mit ihren Redirectoren haben, bedarf es einer Provider DLL, die im Stande ist, mit dem MPR und dem Redirector zu kommunizieren. Der Redirector und die dazugehörige Provider DLL wird von jeweiligen Netzwerkanbieter mitgeliefert. Abbildung 10 verdeutlicht den Zusammenhang zwischen Anwendung und Transport-Protokoll. Anwendungen, die das WNet API (Applikation Programmer Interface) nutzen, fordern mit Hilfe der API-Funktionen eine Verbindung an. Diese wird an den unter ihr liegenden MUP weitergeleitet, der den passenden Redirector aussucht. Abbildung 10: Multi-Provider Router Bei der Installation eines Transport-Protokolls, wird dieser in eine „Rang-Liste“ eingetragen. Der Redirector arbeitet die Liste aller ihm verfügbaren Transport-Protokolle ab und versucht eine Probe-Verbindung aufzubauen. Der Redirector bekommt nach einer gewissen Zeit 14 [Vgl.] MSDN_RK7 Studienarbeit von Sebastian Sehr Seite 16 von 23 Windows NT Netzwerkstruktur Meldungen, welches Transport-Protokol eine erfolgreiche Kommunikation eingehen kann und nimmt von diesen den, mit der höchsten Priorität. 6 Registrierung 6.1 NDIS Protocol Driver Die folgende Darstellung gibt nur einen Einblick und kann unter MSDN_ND_9 nachgelesen werden. Jeder Protocol Driver muss die Eintrittsfunktion DriverEntry besitzen und diese explizit aufrufen, damit der Loader sie identifizieren kann. Die Definition von DriverEntry ist bei jedem Windows NT kernel-mode Driver die selbe. DriverEntry kann auch sogenannte Spin Locks initialisieren, die die Synchronisation der Threads unterstützen. Damit der Protokoll-Driver die NDIS-Funktionen nutzen kann und er als Protocol Driver auch registriert wird, muss dieser NdisRegisterProtocol aufrufen. NdisRegisterProtocol gibt unter anderem den NdisProtocolHandle zurück, der gepeichert werden muss, da er für weitere Ndis-Funktionsaufrufe benötigt wird. Bevor jedoch NdisRegisterProtcol aufgerufen werden kann, müssen folgende Bedingungen erfüllt sein: 1. Mögliche Eintrittspunkte anderer Treiber müssen mit Null initialisiert werden. Diese haben die Struktur NDIS_PROTOCOL_CHARACTERRISTICS und können zum Beispiel mit Hilfe von NdisZeroMemory auf Null gesetzt werden. 2. Die Adressen verwendeter ProtocolXxxx-Funktionen müssen gespeichert werden. 6.1.1 Öffnen eines unterliegenden Adapters Die Registry beinhaltet unter anderem Informationen über mögliche Adapter, an die sich der Protocol Driver binden kann. Bei jeder Installation werden neue Einträge in die Registry eingefügt. Diese Informationen werden von DriverEntry aus der Registry in HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Services\ProtocolComponentName\Linkage gelesen. NdisOpenProtocolConfiguration gibt den Handle für den Registry-Key HKEY_LOCAL_ MACHINE\ SYSTEM\CurrentControlSet\Services\DeviceInstance\Parameters\Protcol Name zurück, wo der Protocl Driver Adapter spezifische Informationen speichern kann. Um diese Inforamtionen zu speichern, kann nur eben angegebene Pfad genutzt werden und es müssen zu dem noch die NDIS- Funktionen NdisRead/WriteConfiguration genutzt werden. Nachdem der Protocol Driver die benötigten Informationen hat und er NdisRegisterProtocol aufgerufen hat, muss er sich noch an einen oder mehrere Netzwerkkarten binden, bevor er Daten senden und empfangen kann. Dafür nutzt er NdisOpenAdapter. Bei diesem Funktionsaufruf übergibt der Protocol Driver der NDIS unter anderem seinen Handle, den die NDIS für spätere Funktionsaufrufe nutzt, wie ProtocolReceive oder ProtocolStatus. Die NDIS ihrerseits gibt dem Protocol Driver ihr Handle zurück, den der Protocol Driver bei Funktionsaufrufen wie NdisSend benötigt. Mit NdisOpenAdapter übergibt der Protocol Driver auch den Adapter-Namen, den er zuvor von der Registry gelesen hat und ein MediumArray. Ist der Funktionsaufruf erfolgreich, wählt Studienarbeit von Sebastian Sehr Seite 17 von 23 Windows NT Netzwerkstruktur der NIC Driver ein Medium von dem MediumArray aus. Damit ist der Protocol Driver an die Netzwerkkarte gebunden und im Stande Daten zu versenden. Protocol Driver Registrierung NdisRegisterProtocol Netzwerkkarte(n) binden NdisOpenAdapter (1) Protocol Driver Handle Abbildung 11 veranschaulicht die Vorgehensweise. Protocol Driver (2) NDIS Handle NDIS Daten Senden NdisSend Abbildung 11: Reihenfolge der Initialisierung des Protocol Drivers 15 7 Résumeé Für die Realisierung des ViAA-Projekts wird ein NDIS Upper Level Protocol Driver benötigt, der zur unteren Schnittstelle die NDIS-Funktionen wahrnimmt und nach oben hin die TDIFunktionen anbietet. In diesem Treiber müssen die ViAA-spezifischen Anforderungen implementiert werden (Netzwerkkarten-Anbindung über die MAC-Adresse und Frameumsetzung). Möchte man die Winsock für den ViAA-Treiber anbieten, wird eine Helper-DLL benötigt (siehe Kapitel 5.1). 8 Abbildungsverzeichnis Abbildung 1:ViAA Szenario ................................................................................................................................... 4 Abbildung 2: The Windows 2000 TCP/IP network model ..................................................................................... 6 Abbildung 3: Windows NT layered architecture .................................................................................................... 7 Abbildung 4:Treiberarten unterhalb der TDI .......................................................................................................... 7 Abbildung 5: Supported Intermediate Driver Configurations ................................................................................. 9 Abbildung 6: NDIS-Interface ................................................................................................................................ 12 Abbildung 7: TDI Clients and Transport Providers .............................................................................................. 13 Abbildung 8: Service Provider Interface ............................................................................................................... 14 Abbildung 9: Windows Sockets Helper DLL Architecture .................................................................................. 15 Abbildung 10: Multi-Provider Router ................................................................................................................... 16 Abbildung 11: Reihenfolge der Initialisierung des Protocol Drivers .................................................................... 18 15 Abbildung: Eigene Zeichnung Studienarbeit von Sebastian Sehr Seite 18 von 23 Windows NT Netzwerkstruktur 9 Abkürzungsverzeichnis API ATM FAQ IP IRPs IRQL ISO LLC MAC MPR MUP NDIS NIC NT OSI QoS TCP TDI UDP WAN Application Programming Interface Asynchronous Transfer Mode Frequently Asked Questions Internet Protocol I/O Request Packets Interrupt Request Level International Organisation of Standardisation Logical Link Control Media Access Control Multi-Provider Router Multiple Universal Naming Convention Provider Network Driver Interface Specification I/O Requests New Technology Open System Interconection Quality of Service Transmission Control Protocol Transport Driver Interface User Datagram Protocol Wide Area Network 10 Quellenangabe 10.1 Referenzierte Quellen dieser Arbeit RL99 ULRICH REMBOLD/ PAUL LEVI: „Einführung in die Informatik für Naturwissenschaftler und Ingenieure“, HanserVerlag SDB97 Siemens AG, Windows NT-Kurs Unterlagen SBD-NTCOMP, Stand 09/97 MSDN Library July 1999 (Verzeichnis : DDK Documentation, Windows NT 4.0 DDK, Network Drivers, Design Guide, …) MSDN_ND1 Verzeichnis: …, Part 1: Network Drivers, Chapter 1: General Network Architecture of Windows, Windows Network Architecture and the OSI Modell MSDN_ND3 Verzeichnis: …, Part 1: Network Drivers, Chapter 1: General Network Architecture of Windows, 1.2 Types of NDIS Drivers, 1.2.2 Transpoer Driver MSDN_ND5 Verzeichnis: Verzeichnis: …,Part 3: Intermediate Drivers and TDI Drivers, Chapter 3 TDI Transports and their Clients Studienarbeit von Sebastian Sehr Seite 19 von 23 Windows NT Netzwerkstruktur MSDN_ND9 Verzeichnis: Verzeichnis: …,Part 3: Intermediate Drivers and TDI Drivers, Chapter 2 NDIS Protocol Drivers MSDN_ND7 …,Part 3: Intermediate Drivers and TDI Drivers, Chapter 6: Transport Helper Dlls for Windows Sockets MSDN_ND12 … Part 3: Intermediate NDIS Driver and TDI Drivers, TDI Drivers and their Clients, The Transport Driver Interface MSDN_ND10 … Part3: Intermediate NDIS Driver and TDI Drivers, Chapter 2: NDIS Protocol Drivers, 2.1 Protocol Driver Entry and Inizialization, 2.1.1. Registering as an NDIS Protocol Drivers MSDN Library July 1999 (Verzeichnis Windows Ressource Kits, Windows NT Server 4.0 Ressource Kit, Windows NT Server 4.0 Networking Guide, Chapter 1: Windows NT Networking Architecture,… MSDN_RK1 …, The Windows NT Networking Architecture, Streams MSDN_RK7 …, The Windows NT Networking Architecture, Network Ressource Access MSDN_SPI http://msdn.microsoft.com/library/default.asp Verzeichnis: Platform SDK, Networking and Directory Services, windows sockets Version 2, Windows Sockets Version 2 SPI, Overviews, Windows sockets 2 Architectural Overviews,... ..., Function Interface Modul ..., Windows Sockets 2 Service Provider ..., Data Transport Providers 10.2 Weitere Quellenangaben MSDN Library July 1999 (Verzeichnis : DDK Documentation, Windows NT 4.0 DDK, Network Drivers, Design Guide,... 10.2.1 Grundlagen und Übersicht für die Programmierung ..., Part 1: Network Drivers, Chapter 1: General Network Architecture of Windows, 1.2 Types of NDIS Drivers, Chapter 2: Network Driver Programming Considerations NDIS-Protokoll-Treiber Verzeichnis: ..., Part 3: Intermediate Drivers and TDI Drivers, Chapter 2: NDIS Protocol Drivers TDI-Funktionen und Helper Dll: Verzeichnis: ..., Part 3: Intermediate Drivers and TDI Drivers, Chapter 3-6 Verzeichnis: ..., Network References, Part 2: TDI,... Studienarbeit von Sebastian Sehr Seite 20 von 23 Windows NT Netzwerkstruktur 10.2.2 Winsock Ausführliche Internet-Seite über die Winsock http://www.stardust.com/winsock/ws_vers.htm#WS2Arch Übersicht Seite über ein Buch „Windows Sockets Network Programming“ http://www.sockets.com/toc.htm 10.3 Weitere Internet Links MSDN online: http://msdn.microsoft.com/library/default.asp DDK-Dokumente für Windows 2000: http://www.microsoft.com/ddk/ddkdocs/win2K/default.htm Netzwerk-Implementierung-Details sind bei Microsoft in den “White Papers” veröffentlicht: http://www.microsoft.com/hwdev/network/ Übersicht und FAQs über TDI und NDIS mit Beispielcode: http://www.pcausa.com/search.htm Ein Glossar für Netzwerke: http://www.whatis.com/ Netzwerk-Implementierung-Details sind in den für Microsoft White Papers veröffentlicht: http://www.microsoft.com/hwdev/network/ DDK-Dokumente für Windows 2000: http://www.microsoft.com/ddk/ddkdocs/win2K/default.htm Studienarbeit von Sebastian Sehr Seite 21 von 23 Windows NT Netzwerkstruktur 11 Anhang A 11.1 Protocolxxx-Functions16 Before making this call, DriverEntry must do the following: 1. Zero-initialize a structure of type NDIS_PROTOCOL_CHARACTERISTICS, for instance with a call to NdisZeroMemory. This assures that unused members for optional entry points are set to NULL. If the structure is not zeroed, any unused members must be set to NULL before calling NdisRegisterProtocol. 2. Store the addresses of the mandatory ProtocolXxx functions, as well as any optional ProtocolXxx functions the driver exports, in the characteristics structure members, as follows: BindAdapterHandler This is an optional function in protocol drivers. A PnP-ready protocol driver specifies this entry point so it can be called by NDIS at the ProtocolBindAdapter function when an adapter is available. Specifying this entry point requires a V4.0 structure at ProtocolCharacteristics. UnbindAdapterHandler This is a required function if the protocol driver registered a ProtocolBindAdapter function. Specifying this entry point also requires a V4.0 structure at ProtocolCharacteristics. OpenAdapterCompleteHandler This is a required function. If a protocol driver’s call to NdisOpenAdapter returns NDIS_STATUS_PENDING, ProtocolOpenAdapterComplete is subsequently called to complete the binding operation. CloseAdapterCompleteHandler This is a required function. If a protocol driver’s call to NdisCloseAdapter returns NDIS_STATUS_PENDING, ProtocolCloseAdapterComplete is subsequently called to complete the unbinding operation. ReceiveHandler This is a required function. ProtocolReceive is called with a pointer to a lookahead buffer. If this buffer contains less than the full, received network packet, ProtocolReceive calls NdisTransferData with a protocol-allocated packet descriptor specifiying protocol-allocated buffer(s) to obtain the remainder of the received packet. ReceiveCompleteHandler This is a required function. ProtocolReceiveComplete is called to indicate that any received packets previously indicated to ProtocolReceive can now be postprocessed. TransferCompleteHandler This is a required function unless the protocol binds itself exclusively to underlying NIC driver(s) that indicate packets with NdisMIndicateReceivePacket. ProtocolTransferDataComplete is called when a previous call to NdisTransferData returned NDIS_STATUS_PENDING and the remaining data has been copied into the protocol-supplied buffers chained to a given packet descriptor. ReceivePacketHandler This is an optional function. A ProtocolReceivePacket function should be provided if the protocol driver might be bound to a NIC driver that indicates an array of one or more packets by calling NdisMIndicateReceivePacket. Specifying this entry point requires a V4.0 structure at ProtocolCharacteristics. 16 Quelle MSDN_ND10 Studienarbeit von Sebastian Sehr Seite 22 von 23 Windows NT Netzwerkstruktur SendCompleteHandler This is a required function. ProtocolSendComplete is called for each packet transmitted with a call to NdisSend that returned NDIS_STATUS_PENDING as the status of the send operation. If an array of packets is sent, ProtocolSendComplete is called once for each packet passed to NdisSendPackets, whether or not it returned pending. ResetCompleteHandler This is a required function. ProtocolResetComplete is called when a protocol-initiated reset operation, begun with a call to NdisReset that returned NDIS_STATUS_PENDING, is completed. RequestCompleteHandler This is a required function. ProtocolRequestComplete is called when a protocolinitiated query or set operation, begun with a call to NdisRequest that returned NDIS_STATUS_PENDING, is completed. StatusHandler This is a required function. ProtocolStatus is called to handle status changes indicated by the underlying NDIS driver. StatusCompleteHandler This is a required function. ProtocolStatusComplete is called by NDIS, along with ProtocolStatus, to report the start and end of an NDIS- or NIC-driver-initiated reset operation. A protocol driver should set the ProtocolCharacteristics TranslateHandler and UnloadHandler members to NULL. The TranslateHandler member is reserved for future use. NDIS never calls an entry point specified in UnloadHandler on Windows NT platforms. Instead, the Windows NT I/O Manager calls the Unload routine that the protocol driver sets in the driver object passed in to the protocol's DriverEntry function. Studienarbeit von Sebastian Sehr Seite 23 von 23
