Entwicklung eines Winsock2-API-Monitors. Ali Fessi AG Integrierte Kommunikationssysteme, Prof. Müller Betreuer: Bernd Reuther

Transkript

1 Entwicklung eines Winsock2-API-Monitors Ali Fessi AG Integrierte Kommunikationssysteme, Prof. Müller Betreuer: Bernd Reuther

2 Inhaltsverzeichnis 1. Motivation Überblick TracePlus/Winsock Grundlagen Dynamic Link Libraries Allgemeines über DLLs Vorteile von DLLs Exportieren von Funktionen aus einer DLL Implizites und Explizites Linken Suchpfad nach einer DLL Memory Sharing zwischen DLLs Architektur der Winsock2-API Unterstützung mehrerer Protokoll-Familien Kompatibilität mit Winsock1.1 Applikationen Befehle für die Datenkommunikation Blockierende und nicht-blockierende Funktionen Entwicklung Erster Ansatz: Implementierung einer neuen Winsock2-DLL Automatisches Erzeugen des Codes Implementierungsaspekte Installation Zweiter Ansatz: Die Debug/Trace Version der Winsock2-DLL Architektur der Debug/Trace Version der Winsock2-DLL WSAPreApiNotify und WSAPostApiNotify Implementierung Zusammenfassung beider Ansätze Daten erfassen und visualisieren Winsock2-API-Monitor Performance Monitor LOG-Datei Ausgabe der LOG-Dateien Performance Factor Übersetzung der LOG-Datei Installation Konfigurationsprogramm Zusammenfassung und Ausblick Literaturverzeichnis

3 1. Motivation Netzwerktechnologien und Kommunikationsprotokolle ermöglichen dem Nutzer bzw. den Applikationen verschiedene Dienste zu nutzen. ATM-Netzwerke bieten z.b. die Möglichkeit, für jede einzelne Verbindung einen QoS auszuhandeln. Soll diese Möglichkeit genutzt werden, dann müssen detaillierte Informationen über Kommunikationsanforderungen der Applikation an die unteren Netzwerkschichten vorliegen. Dazu gehört zum einen der Bandbreitenbedarf einer Applikation, z.b. Häufigkeit, Dauer, oder dauerhaft genutzte Bandbreite. Zum anderen gehören dazu Anforderungen an die Übertragungsqualität, z.b. Verzögerung, Verzögerungsschwankungen oder durchschnittliche Datenverlustraten. Die Anwendungen im Bereich der Internetkommunikation variieren zwischen einfachem Datenaustausch und komplexen interaktiven Multimedia-Applikationen. Demnach stellen die Applikationen unterschiedliche Anforderungen an die Netzwerkschnittstelle. Es gibt viele Programme, die es erlauben, den Datenaustausch auf unteren Ebenen zu kontrollieren. Die so genannten Sniffer erlauben es, den Datenverkehr auf dem Ethernet, was dem Layer 2 des ISO/OSI-Modells entspricht, zu beobachten. Andere Programme sind in der Lage, Statistiken über die IP-Pakete (Layer 3) bzw. TCP- oder UDP-Pakete (Layer 4) zu erstellen. Mit diesen Programmen kann man allerdings keine Aussagen über die Anforderungen einer Applikation und ihr Verhalten an der API (Application Programmer Interface) treffen. 2. Überblick In dieser Arbeit wird ein Tool entwickelt, das die Analyse des Verhaltens der Applikationen an der API-Schnittstelle ermöglicht. Das Tool erfasst die Aufrufe von Netzwerkfunktionen mit ihren Parametern, z.b. die Paketgröße beim Senden und Empfangen. Zuerst wird mit TracePlus /Winsock" ein kommerzielles Tool vorgestellt, das diese Aufgabe erfüllt. Die Vor- und Nachteile von TracePlus werden beschrieben. Danach wird ein eigenes Tool entwickelt. Es werden zum Teil die Parameter, mit denen die Netzwerkfunktionen aufgerufen werden, protokolliert. Es werden Zeitstempel geschrieben, damit eine genauere Analyse der QoS-Anforderungen der Applikationen möglich wird. Das Tool wird auf der Plattform Windows2000 entwickelt. Die API ist Winsock2, die in der DLL (Dynamic Link Library) Ws2_32.dll realisiert ist. Bevor die Entwicklung des Tools beschrieben wird, werden einige Grundlagen über DLLs und über die Winsock2- API vorgestellt. Die Entwicklung des Tools selbst gliedert sich in zwei Schritte: - 2 -

4 Der erste Schritt ist die Erfassung der Funktionsaufrufe der Winsock2-API mit ihren Parametern. Hier soll ein Verfahren implementiert werden, welches den Zugriff auf die Schnittstelle zwischen den Applikationen und der Winsock2-API ermöglicht (siehe Abb.1). Zwei Verfahren werden vorgestellt: a) Im ersten Verfahren wird eine neue Winsock2-DLL implementiert, welche die alte DLL ersetzt. b) Im zweiten Verfahren wird eine spezielle Version der Winsock2-DLL verwendet: die so genannte Debug/Trace Version. Es wird eine Dt_DLL (Dt steht für Debug/Trace) geschrieben, mit der die Winsock2-DLL kommuniziert. Der zweite Schritt ist die Visualisierung der Funktionsaufrufe mit ihren Parametern. Hier werden drei Verfahren diskutiert: a) Anzeigen der Funktionsaufrufe durch einen Winsock2-API-Monitor b) Visualisieren der Funktionsaufrufe mit dem Performance Monitor (PerfMon.exe). c) Protokollieren der relevanten Daten in einer LOG-Datei und Visualisieren dieser Daten nachträglich, z.b. in Excel-Diagrammen Applikation API Messung Winsock2 Abb.1: Vereinfachte Beschreibung des Winsock2-API-Monitoring Anschließend wird jeweils ein Verfahren ausgewählt und ein Einblick in die Auswertung gemacht

5 3. TracePlus /Winsock TracePlus ist ein Tool, das in der Lage ist, Prozesse zu starten und die Winsock2-API- Aufrufe auf einem Monitor anzuzeigen oder in einer Datei zu speichern. Abb. 2 zeigt, wie TracePlus den Internet Explorer startet und die Winsock2-API-Aufrufe anzeigt. Abb.2: API View von TracePlus mit dem Internet Explorer. Bei einem gestarteten Prozess verfügt TracePlus über vier verschiedene Fenster: API View, Data View, Socket View und Packet Statistics. API View zeigt die Aufrufe der Winsock2-Funktionen mit ihren Parametern und mit Zeitstempeln an. Data View stellt den Inhalt der gesendeten bzw. empfangenen Pakete dar. Eine Unterscheidung zwischen ASCII- und hexadezimalen Daten ist möglich. Socket View verfolgt die Änderung des Zustands eines Sockets während seines Lebenszyklus (Allocated, Bound, Connected, Closed, Blocking, Not Blocking). Packet Statistics zeigt weitere Informationen über die gesendeten und empfangenen Pakete an: Paketgröße, Sende- bzw. Empfangszeitpunkt und Zeitspanne beim Senden oder Empfangen mit einer Genauigkeit von Millisekunden. Eine Demo-Version von TracePlus kann unter herunter geladen werden. Dieses Programm ist gut geeignet, um einige Internetanwendungen zu debuggen oder Erkenntnisse über bestehende Anwendungen zu gewinnen. Man kann - 4 -

6 z.b. genaue Informationen über das HTTP-Protokoll erhalten, wenn man TracePlus mit einem Internet Browser startet. Doch für zeitkritische Anwendungen wie Voice Over IP oder Multimediaanwendungen hilft uns TracePlus nicht weiter: Die Genauigkeit der Zeitangaben in Millisekunden ist zu grob. Innerhalb einer Millisekunde können mehrere Funktionen aus der Winsock2-API aufgerufen werden, insbesondere kann mehrmals gesendet und empfangen werden. Außerdem zeigt der Test von TracePlus enttäuschende Ergebnisse: TracePlus stürzt einfach ab, wenn es zusammen mit der Voice Over IP Anwendung HiNet Xpress gestartet wird. Bei Netmeeting ist TracePlus nicht in der Lage, die Funktionsaufrufe der Winsock2 zu verfolgen. Das Tool liefert einfach gar keine Ausgaben. Dadurch zeigt sich, dass TracePlus für unsere Anforderungen nicht geeignet ist. Multimedia-Anwendungen sind ein wichtiges Gebiet, in dem die Analyse der Anforderung einer Applikation an der API-Schnittstelle von Bedeutung ist. Der Inhalt der gesendeten und empfangenen Daten ist nicht relevant, denn es handelt sich meistens nicht um ASCII-Daten. Deshalb wurde in dieser Arbeit auf dieses kommerzielle Tool verzichtet und ein eigenes Programm entwickelt. 4. Grundlagen In diesem Abschnitt werden Grundlagen über DLLs (Dynamic Link Libraries) und über die Winsock2-API vorgestellt, die für das Verständnis dieser Arbeit erforderlich sind. 4.1 Dynamic Link Libraries Hier werden DLLs definiert und ihre Charakteristika vorgestellt Allgemeines über DLLs DLLs sind Module, die Funktionen enthalten, welche von anderen Modulen aufgerufen werden können. Eine DLL wird zur Laufzeit durch ein anderes Modul (eine ausführbare EXE-Datei oder eine andere DLL) geladen. Eine Instanz der DLL mit den zugehörigen Variablen wird an den Speicherbereich, der für den laufenden Prozess reserviert ist, angehängt. DLLs können zwei Arten von Funktionen definieren: externe und interne Funktionen. Externe Funktionen können von anderen Modulen aufgerufen werden. Interne Funktionen können nur innerhalb der DLL selbst verwendet werden

7 4.1.2 Vorteile von DLLs Es gibt mehrere Gründe, DLLs einzusetzen: Erstens lässt sich die Größe der ausführbaren Anwendungsdateien verringern, indem man die von mehreren Anwendungen gemeinsam genutzte Funktionalität in DLLs unterbringt. Zweitens kann der Code der DLLs aktualisiert und modifiziert werden, ohne die ausführbare Anwendung neu kompilieren zu müssen. Man kann sogar neue Funktionen implementieren und exportieren, die neuen Anwendungen bereitgestellt werden, ohne dabei alte Anwendungen zu beeinflussen. Schließlich kann man DLLs mit nahezu jeder anderen Programmiersprache unter Windows verwenden. Die Win32-API ist als Sammlung von DLLs implementiert. Die Winsock2-API ist z.b. in der Datei Ws2_32.dll implementiert. In den nächsten zwei Abschnitten wird beschrieben, wie man Funktionen aus einer DLL exportieren und in ein Modul importieren kann Exportieren von Funktionen aus einer DLL Eine DLL ist ähnlich aufgebaut wie eine ausführbare Datei, allerdings gibt es zwei entscheidende Unterschiede: Eine DLL ist allein nicht ausführbar. Eine DLL besitzt eine Export-Tabelle. In der Export-Tabelle stehen die Namen der Funktionen, die von der DLL exportiert werden. Die Export-Tabelle einer DLL kann man sich mit dem DOS-Befehl DUMPBIN oder mit dem Programm Dependency Walker 1 anschauen. Als Beispiel betrachten wir hier eine einfache DLL, die zwei Funktionen exportiert: gimme_a_string1 und gimme_a_string2. 1 Ein Tool von Visual C

8 const char * gimme_a_string1(void) { return "Hello "; } const char * gimme_a_string2(void) { return "World\n"; Listing 4.1: Implementierung von gimme_a_string1 und gimme_a_string2. Diese zwei Funktionen sollen in einer ausführbaren Datei wie folgt aufgerufen werden: printf(gimme_a_string1()); printf(gimme_a_string2()); Listing 4.2: Aufruf von gimme_a_string1 und gimme_a_string2. Damit wird die gesamte Ausgabe Hello World. Es gibt zwei Methoden, eine Funktion aus einer DLL zu exportieren: Mit dem Schlüsselwort declspec(dllexport) (siehe Listing 4.3) Mit einer DEF-Datei, die verwendet wird, um die Export-Tabelle zu definieren. (siehe Listing 4.4)... declspec(dllexport) const char * gimme_a_string1(void); declspec(dllexport) const char * gimme_a_string2(void);.. Listing 4.3: Exportieren mit declspec(dllexport) LIBRARY STR_DLL DESCRIPTION "a sample for using DLLs" ; Here goes explicit function export EXPORTS gimme_a_string1 gimme_a_string2 Listing 4.4: Exportieren mit einer DEF-Datei. Die Interpretation einer DEF-Datei durch den Linker bietet auch einige Freiheiten: Es gibt z.b. die Möglichkeit, eine Funktion mit einem anderen Namen zu exportieren als der Name, mit dem sie in dem Code der DLL definiert wird; z.b.: - 7 -

9 EXPORTS string1 = gimme_a_string1 string2 = gimme_a_string2 Listing 4.5: Exportieren mit anderen Namen. Diese beiden Funktionen werden im Code mit gimme_a_string1 und gimme_a_string2 definiert und sind nach außen nur mit string1 bzw. string2 sichtbar. Es besteht auch die Möglichkeit, Funktionen aus anderen DLLs zu exportieren; z.b.: EXPORTS gimme_a_string1 gimme_a_string2=proxy_dll.gimme_a_string2 Listing 4.6: Exportieren aus anderen DLLs. In diesem Beispiel wird die Funktion gimmme_a_string2 exportiert, die in Proxy_Dll.dll implementiert ist. Wenn die Implementierung der Funktion gimme_a_string2 in der Proxy_Dll wie folgt aussieht, const char * gimme_a_string2(void) { return "Bob\n"; } Listing 4.7: Implementierung von gimme_a_string2 in Proxy_Dll. dann ist die gesamte Ausgabe des Programms Hello Bob und nicht Hello World. In diesem Fall muss die Datei STR_DLL.dll mit der Proxy_DLL.lib durch den Linker verknüpft werden Implizites und Explizites Linken Das übliche Verfahren, eine Funktion in ein Modul zu importieren, besteht darin, die Funktion mit dem Schlüsselwort declspec(dllimport) in dem Code des Moduls zu deklarieren... declspec(dllimport) const char * gimme_a_string1(void); declspec(dllimport) const char * gimme_a_string2(void);.. Listing 4.8: Importieren mit declspec(dllimport). Wenn man mit dem Entwicklungstool Visual C++ eine DLL erzeugt, wird eine Header- Datei erzeugt, die sowohl für die DLL als auch für die Module, welche diese DLL - 8 -

10 verwenden, benutzt werden kann. Mit dem Makro STR_DLL_EXPORTS kann man den Fall jeweils unterscheiden. Dieses Makro wird in der DLL von Visual C++ automatisch definiert. 2 #ifdef STR_DLL_EXPORTS #define STR_DLL_API declspec(dllexport) #else #define STR_DLL_API declspec(dllimport) #endif Listing 4.9: Abkürzung von declspec(dllimport) und declspec(dllexport) mit Hilfe eines Makros. Beim Kompilieren der DLL wird zusätzlich zu der Datei STR_DLL.dll eine Datei STR_DLL.lib erzeugt. Module, die Funktionen aus der DLL benutzen sollen, müssen mit dieser LIB-Datei durch den Linker verknüpft werden, damit die Bezeichnungen gimme_a_string1 und gimme_a_string2 im Programmcode aufgeschlüsselt werden können. Die Funktionen gimme_a_string1 und gimme_a_string2 können so aufgerufen werden, als ob sie in demselben Modul definiert wären. Dieses Verfahren heißt Implizites Linken. Doch es gibt ein zweites Verfahren, eine DLL zur Laufzeit zu linken: Die DLL wird explizit mit dem Befehl LoadLibrary geladen. Die Funktionen werden mit dem Befehl GetProcAddress gesucht und können über einen Pointer to function ausgeführt werden... typedef const char* (*LPFN_GIMME_A_STRING)(void); // declare type pointer to function.. HINSTANCE hdll; // handle to DLL LPFN_GIMME_A_STRING lpfn_gimme_a_string1; // declare function pointer LPFN_GIMME_A_STRING lpfn_gimme_a_string2; // declare function pointer.. hdll = LoadLibrary("STR_DLL");... lpfn_gimme_a_string1 = (LPFN_GIMME_A_STRING)GetProcAddress(hDLL,"gimme_a_string1");... lpfn_gimme_a_string2 = (LPFN_GIMME_A_STRING)GetProcAddress(hDLL,"gimme_a_string2");... printf(lpfn_gimme_a_string1()); printf(lpfn_gimme_a_string2());.. Listing 4.10: Explizites Linken. 2 Wähle das Projekt der DLL aus; gehe auf dem Menü Project/Settings und dann auf der Seite C/C++ sieht man bei Preprocessor definitions die vordefinierten Makros

11 4.1.5 Suchpfad nach einer DLL Wenn eine DLL geladen werden soll, muss das Betriebssystem die DLL finden. Der Suchpfad der DLL ist wie folgt aufgebaut: Die DLL wird zunächst im Verzeichnis gesucht, in dem sich die ausführbare Datei befindet. Falls die Suche erfolglos war, wird in einem durch die globale Variable PATH definierten Pfad gesucht. Der Pfad kann mit dem DOS-Befehl PATH gelesen und verändert werden. Wenn die DLL nicht gefunden wird, gibt es eine Fehlermeldung vom Betriebssystem. Bei manchen DLLs, die durch das Betriebssystem selbst verwendet werden, (z.b. die Ws2_32.dll) kann das System gar nicht gestartet werden! Memory Sharing zwischen DLLs Der entscheidende Vorteil der DLLs ist, dass mehrere Prozesse sich ein Code-Segment teilen. Das Code-Segment wird geteilt, aber jeder Prozess besitzt sein eigenes Daten- Segment; d.h. wenn n Prozesse eine DLL laden, dann gibt es n Instanzen der DLL und ein einziges Segment für den Code. Wenn das Betriebssystem eine DLL lädt, die von einem Prozess benötigt wird, dann wird eine Instanz dieser DLL am Speicherbereich des Prozesses angehängt. Dieser Bereich wird vom Betriebssystem streng eingegrenzt und von anderen Prozessen getrennt. Doch es gibt einen Mechanismus, mit dem mehrere Prozesse auf die gleichen Daten parallel zugreifen können. Das von [24] übernommene Listing 4.10 beschreibt, wie die Daten in der DLL deklariert werden müssen, damit sie nicht bei jedem Prozess neu initialisiert werden und von allen Prozessen, die diese DLL laden, geteilt werden. // Global and static member variables that are not shared.... #pragma data_seg("shared") // Begin the shared data segment. // Define simple variables // Integers, char[] arrays and pointers // Do not define classes that require 'deep' copy constructors. #pragma data_seg() // End the shared data segment and default back to // the normal data segment behavior. // tell to the linker that there variables have to be shared with other processes. #pragma comment(linker, "/section:shared,rws") Listing 4.11: Memory Sharing zwischen DLLs. Der Zugriff auf die gemeinsamen Daten sollte mit einer Critical Section synchronisiert werden

12 4.2 Architektur der Winsock2-API In diesem Abschnitt werden die neuen Konzepte, welche die Winsock2 enthält, beschrieben. Unter anderem wird hier die Unterstützung anderer Protokoll-Familien außer TCP/IP hervorgehoben Unterstützung mehrerer Protokoll-Familien Im Gegensatz zu der Winsock1.1 unterstützt die Winsock2 mehrere Protokoll-Familien und nicht nur die Protokolle der TCP/IP-Suite. Die Schnittstelle zwischen der Winsock- DLL und dem unterliegenden Protokoll-Stack ist bei Winsock1.1 nur für TCP/IP geeignet. Winsock2 bietet eine einheitliche Schnittstelle (SPI) für alle Transport Service Provider und Name Service Provider. Die Einführung eines neuen Service Providers erfordert nicht die Implementierung einer neuen Ws2_32.dll sondern nur die Anpassung an die SPI-Schnittstelle. Abb. 2 ist von der MSDN-Library übernommen und zeigt die Architektur der Winsock2 mit beiden API- und SPI-Schnittstellen. Die Winsock2-DLL ist ein Interface zwischen den Applikationen und den Service Providern. In der Winsock2 selbst sind keine Protokolle implementiert. Wenn eine Applikation ein Socket anlegen will, ruft sie die Funktion socket mit dem passenden Wert des Arguments type auf. SOCKET socket(int af, int type, int protocol ); Listing 4.12: Prototyp von socket. 3 Die gängigsten Socket-Typen sind TCP (type = 1) und UDP (type = 2). Die Funktion WSCEnumProtocols wird dann an der SPI-Schnittstelle aufgerufen, um Informationen über die installierten Transportprotokolle zu finden. WSCEnumProtocols ist mit der API-Funktion WSAEnumProtocols vergleichbar. Mit WSAEnumProtocols kann die Applikation selbst Informationen über die installierten Protokolle herausfinden und eventuell dynamisch ein Transportprotokoll wählen. 3 SOCKET ist ein Makro für unsigned int. Ein Socket Descriptor ist also ein unsigned int

13 Abb.2: Unterstützung mehrerer Protokoll-Familien durch die Winsock Kompatibilität mit Winsock1.1 Applikationen Winsock2 unterstützt auch Applikationen, die mit Winsock1.1. entwickelt wurden. Mit einer Kompatibilitätskomponente kann jede Applikation, die mit der Winsock1.1 ausführbar ist, an die Winsock2 zur Laufzeit angepasst werden. Die Funktion WSAStartUp wird beim Laden der Winsock2-DLL als erste aufgerufen. In dieser Funktion wird ausgehandelt, welche Version der Winsock-DLL die Applikation unterstützt und danach wird entschieden, ob die Winsock-Aufrufe durch die Kompatibilitätskomponente gehen sollen

14 Abb.3: Unterstützung von Winsock1.1-Applikationen durch die Winsock Befehle für die Datenkommunikation Der Datenverkehr läuft über Sockets. Die Sockets werden mit dem Befehl socket oder WSASocket aufgebaut und mit closesocket geschlossen. Bei Server-Applikationen können mit dem Befehl accept zusätzlich Sockets angelegt werden. Die Datenkommunikation selbst geschieht mit send, sendto, recv, recvfrom, WSASend, WSASendTo, WSARecv oder WSARecvFrom. Bei send, recv, sendto und recvfrom ist die Paketgröße über dem Parameter len zu finden. int send(socket s, const char FAR *buf, int len, int flags); Listing 4.13: Prototyp von send. WSASend und die anderen Funktionen ermöglichen einer Applikation das Senden bzw. Empfangen einer Menge von Datenpuffern, die in einem Array gespeichert wird. Damit kann man das zweifache Kopieren der Daten vermeiden, welches bei einzelnen Aufrufen von einfachen Send- und Receive-Befehlen entstehen würde

15 int WSASend( SOCKET s, LPWSABUF lpbuffers, DWORD dwbuffercount, LPDWORD lpnumberofbytessent, DWORD dwflags, LPWSAOVERLAPPED lpoverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpcompletionroutine); lpbuffers ist das Array mit den Datenpuffern und lpnumberofbytessent ist ein Array mit den jeweiligen Größen des Puffers. Für unsere Ziele betrachten wir die gesamte Menge der Daten als ein Paket und rechnen die Summe der Puffergrößen zusammen Blockierende und nicht-blockierende Funktionen Man kann unter den Netzwerkfunktionen zwischen zwei Kategorien unterscheiden: Funktionen, die sofort beendet werden z.b. bind, getsockopt, getpeername, Funktionen, die für ihre Ausführung eine unvorhersehbare Zeit brauchen, z.b. recv. Die Funktion recv blockiert den Prozess, bis Daten aus dem anderen Rechner ankommen. Bei BSD-Sockets und früheren 16-Bit-Windows-Sockets1.1 muss eine solche blockierende Funktion wie folgt behandelt werden. Es wird in einer Schleife und in regelmäßigen Abständen geprüft, ob neue Daten im Puffer angekommen sind. Falls ja, wird recv aufgerufen und die Schleife abgebrochen. Somit wird der gesamte Prozess nicht blockiert und andere Threads können parallel zu der Schleife weiter laufen. 5. Entwicklung Listing 4.14: Prototyp von WSASend. 5.1 Erster Ansatz: Implementierung einer neuen Winsock2-DLL Im Abschnitt 4.1 wurden einige Eigenschaften von DLLs aufgezählt. Wie schon erwähnt, kann der Code einer DLL geändert werden, ohne die Applikationen, die diese DLL benutzen, neu kompilieren zu müssen. D.h. wenn wir eine neue DLL namens Ws2_32.dll schreiben und die alte Winsock2 DLL zu Ws2_32Back.dll umbenennen, dann wird bei Netzwerkanwendungen die neue DLL geladen. In diesem Ansatz wird eine neue Winsock2-DLL implementiert, welche die gleichen Funktionen exportiert wie die alte Winsock2. Diese Funktionen rufen selbst die gleichen Funktionen aus der alten Winsock2-DLL auf und können dazwischen die Funktionsaufrufe und ihre Parameter protokollieren. Abb. 4 veranschaulicht dieses Verfahren

16 Ws2_32.dll 4 1 I 2 Ws2_32Back.dll II 3 Abb.4: Implementierung einer neuen Winsock2-DLL. Bsp. Die Funktion socket. (1) Eine Applikation ruft die Funktion socket aus der neuen Winsock2. Die neue Winsock2 hat die Möglichkeit in (I) Parameter und Zeitstempeln zu protokollieren. (2) Die neue Winsock2 ruft sie die Funktion socket aus der alten Winsock2. (3) Die alte Winsock2 gibt einen Socket Descriptor zurück. Die neue Winsock2 kann in (II) wieder protokollieren. (4) Die neue Winsock2 liefert den Socket Descriptor zu der Applikation zurück. Innerhalb der Funktion socket muss die ursprüngliche socket -Funktion von Ws2_32Back aufgerufen werden. Die Bezeichnung der neuen Funktion ist socket, um eine Rekursion im Code zu vermeiden. SOCKET socket(int af, int type, int protocol){.. socket (int af, int type, int protocol).. } Listing 5.1: Implementierung von socket in der neune Winsock2-DLL. Diese Bezeichnung socket wird in der DEF-Datei maskiert: EXPORTS. socket = socket. Listing 5.2: Eintrag von socket in der DEF-Datei. Doch damit socket innerhalb von socket aufgerufen werden kann, muss socket importiert werden und die LIB-Datei der alten Winsock2-DLL Ws2_32.lib muss mit der neuen Winsock2-DLL durch den Linker verknüpft werden. Abb. 5 stellt diese Idee dar

17 Ws2_32.lib 1 2 Ws2_32.dll Export-Tabelle Code accept accept {...} bind bind {...} socket socket(...){... socket(...);... } Ws2_32Back.dll Export-Tabelle Code accept accept (...){...} bind bind (...){...} socket socket(...){...} Abb.5: Implementierung neuer Winsock2-Funktionen mit Hilfe von alten Funktionen. Beispiel: socket. (1) Die alte Funktion socket wird innerhalb des Codes der neuen Funktion socket aufgerufen. Das Betriebssystem sucht in Ws2_32.lib, wie das Code-Segment der alten Funktion socket zu erreichen ist. (2) Die Datei Ws2_32.lib soll darauf hinweisen, dass socket in Ws2_32Back implementiert ist und einen Pointer to function auf socket liefern. Allerdings weist Ws2_32.lib darauf hin, dass die Funktion socket in der Datei Ws2_32.dll ist, die jetzt Ws2_32Back.dll heißt. Abb. 6 zeigt, was bei dem Aufruf von socket innerhalb von socket tatsächlich geschieht. Die LIB-Datei ist auch in Binärcode geschrieben, so dass eine effiziente kleine Änderung nicht möglich ist

18 Ws2_32.lib 1 2 Ws2_32.dll Export-Tabelle Code accept accept {...} bind bind {...} socket socket(...){... socket(...);... } Ws2_32Back.dll Export-Tabelle Code accept accept (...){...} bind bind (...){...} socket socket(...){...} Abb.6: Implementierung neuer Winsock2-Funktionen mit Hilfe von alten Funktionen am Beispiel von socket. (1) Die alte Funktion socket wird innerhalb des Codes der neuen Funktion socket aufgerufen. Das Betriebssystem sucht in Ws2_32.lib, wie das Code-Segment der alten Funktion socket zu erreichen ist. (2) Die Datei Ws2_32.lib weist darauf hin, dass die Funktion socket in der Datei Ws2_32.dll implementiert ist. Es ergibt sich eine Rekursion. Die Datei Ws2_32.lib ist immer erforderlich, wenn Funktionen aus einer DLL implizit importiert werden. In dem Beispiel von Explizitem Linken im Abschnitt scheint der Aufruf von exportierten Funktionen umständlich zu sein. Doch hier eignet sich das explizite Linken gut. SOCKET socket( int af, int type, int protocol) { /* evtl. Parameter und Zeit Ausgabe */. LPFN_SOCKET lpfn_socket = (LPFN_SOCKET)GetProcAddress(hDLL,"socket"); SOCKET rt = lpfn_socket( af, type, protocol); /* evtl. noch mal Parameter und Zeit Ausgabe */... return rt; } Listing 5.3: Implementierung von socket mit Explizitem Linken

19 Dazu muss die Ws2_32Back.dll in der Dll_Main der neuen DLL geladen werden. Dll_Main wird aufgerufen, wenn ein Prozess die DLL lädt und wenn der Prozess die DLL freigibt (meistens wird die DLL erst freigegeben, wenn der Prozess beendet wird). Dll_Main wird auch bei jedem Thread-Beginn und -Ende aufgerufen. Listing 5.4 zeigt den Code von Dll_Main in der neuen Winsock2 DLL. Das Argument ul_reason_for_call weist darauf hin, um welchem Fall es sich gerade handelt. BOOL APIENTRY Dll_Main( HANDLE hmodule, DWORD ul_reason_for_call, LPVOID lpreserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: hdll = LoadLibrary("Ws2_32Back"); if (!hdll) exit(-1); /* weitere Initialisierungen */... break; case DLL_THREAD_ATTACH: if(!hdll) { hdll = LoadLibrary("Ws2_32Back"); if (!hdll) exit(-1);... } break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: FreeLibrary(hDLL);... break; } return TRUE; } Listing 5.4: Implementierung von Dll_Main in der neuen Winsock2-DLL. Die Funktionen werden mit einer DEF-Datei exportiert:

20 LIBRARY WS2_32 EXPORTS ; Here goes the explicit export declaration Listing 5.5: Die DEF-Datei der neuen Winsock2-DLL. Die Zahlen, die in der rechten Spalte stehen, sind so genannte Ordinals. Hier werden die Funktionen mit einer Ordnungszahl exportiert. In [6] wird das Exportieren von Funktionen mit einer Ordnungszahl erklärt. Aus Effizienzgründen werden auch alle Pointer to function (lpfn_accept, lpfn_bind ) als globale Variablen deklariert und einmalig in der DllMain berechnet. Eine grobe Zeitmessung zeigt, dass die Berechnung aller dieser Pointer to function weniger als eine Millisekunde dauert. Dadurch wird die Applikation beim Laden der DLL nur unbedeutend beeinflusst. Der Code einzelner Funktionen reduziert sich wie folgt. SOCKET socket( int af, int type, int protocol) { /* evtl. Parameter und Zeit Ausgabe */. SOCKET rt = lpfn_socket( af, type, protocol); /* evtl. noch mal Parameter und Zeit Ausgabe */... return rt; } Listing 5.6: Reduzierte Implementierung von socket in der neuen Winsock2-DLL Automatisches Erzeugen des Codes Es ist nicht denkbar, den Code aller Funktionen per Hand zu schreiben, denn dies beansprucht mühsame Arbeit und ist sehr fehleranfällig. Diese Vorgehensweise erschwert jede Änderung oder Erweiterbarkeit des Codes. Deshalb wird der Code mit einem Perl-Script automatisch erzeugt. Der Code der Funktionen besitzt dieselbe Struktur. Die Funktionsprototypen werden aus den Dateien winsock2.h und ws2spi.h ausgelesen und in einer Datenstruktur gespeichert. Anschließend kann der Code aus dieser Datenstruktur automatisch erzeugt werden. Einige kleine Änderungen werden zusätzlich von Hand gemacht

21 5.1.2 Implementierungsaspekte Bei der Entwicklung der Winsock2 wurden einige Aspekte festgestellt, die hier erläutert werden. Die Winsock2-DLL muss vollständig implementiert werden, bevor sie einsatzbereit ist. Selbst einfache Client- oder Server-Applikationen, die nur wenige Funktionen aus der BSD-Familie wie accept, socket, listen, send und recv anwenden, können nicht laufen, wenn die Implementierung sich auf solche Funktionen beschränkt. Es gibt andere Funktionen, die erforderlich sind, selbst wenn sie nicht explizit durch die Applikation aufgerufen werden. Die Funktion WSAStartup z.b. wird, wie im Abschnitt schon erwähnt, immer als erste aufgerufen. Sie bestimmt, auf welche Version der Winsock-DLL die Applikation zugeschnitten ist, und setzt eventuell die Kompatibilitätskomponente ein. Keine weitere Funktion aus der Winsock2-DLL kann aufrufen werden, wenn WSAStartup nicht erfolgreich abgeschlossen wird (d.h. der Rückgabewert ist gleich Null). Weitere Funktionen sind erforderlich, um Sockets anzulegen. Wird socket von einer Applikation aufgerufen, so wird WSCEnumProtocols aufgerufen, um die erforderlichen Informationen über die auf dem Rechner installierten Service Provider zu finden (siehe Abschnitt 4.2.1). Der erste Service Provider, der die gewünschte Adressfamilie und den Typ des Sockets unterstützt, wird verwendet. Solange WSCEnumProtocols von der Winsock2-DLL nicht exportiert wird, können keine Sockets angelegt werden und dadurch auch keine Daten ausgetauscht werden. Der Rückgabewert von socket ist immer INVALID_SOCKET Installation Nachdem die neue Winsock2-DLL mit verschiedenen Internetanwendungen erfolgreich getestet wurde, kann sie im System installiert werden (siehe auch Abschnitt 7). Beim Systemstart werden einige Prozesse gestartet, welche die Winsock2-DLL laden. Bei Windows 2000 werden z.b. WinMgmt.exe, winlogon.exe, services.exe und weitere Programme gestartet. Die neue Winsock2-DLL wurde von diesen Prozessen fehlerfrei verwendet und das System ist erfolgreich gestartet. Dieser Schritt der Entwicklung hatte eine besondere Bedeutung. Dadurch zeigte sich, dass die neue Winsock2-DLL die gleiche Funktionalität erfüllen kann wie die ursprüngliche Winsock2-DLL. Der bisher beschriebene Ansatz hat mit unseren Anforderungen übereingestimmt. Durch seine Entwicklung wurden viele Erkenntnisse über DLLs allgemein und insbesondere über die Winsock2-DLL gewonnen. Doch wir haben uns schließlich für einen anderen Ansatz entschieden. Im nächsten Abschnitt werden der zweite Ansatz und seine Vorteile vorgestellt

22 5.2 Zweiter Ansatz: Die Debug/Trace Version der Winsock2-DLL Die Microsoft Platform SDK bietet eine wenig bekannte Version der Winsock2-DLL. Diese Version wird als Debug/Trace Winsock2 bezeichnet. Sie ist fast auf unsere Anforderungen zugeschnitten. Sie wurde veröffentlicht mit dem Ziel, Entwicklern beim Debugging ihrer Internetanwendungen zu unterstützen. Mit dieser DLL können die Entwickler die Funktionsaufrufe der Winsock2 nachvollziehen. Sie ermöglicht eine volle Kontrolle über die Parameter, mit denen diese Funktionen aufgerufen werden, und über die jeweiligen Rückgabewerte. Diese Werte können eventuell modifiziert werden. Ein Funktionsaufruf kann vorgetäuscht werden. Diese DLL ermöglicht auch die Kontrolle über die Winsock2-Funktionsaufrufe durch andere DLLs, in denen Service Provider implementiert sind. Mit anderen Worten: wir haben nicht nur die Kontrolle über die API-Schnittstelle, sondern auch über die SPI- Schnittstelle. Diese DLL soll Entwicklern dabei helfen, auftretende Probleme in der Applikation, in der Winsock2 oder im Service Provider zu lokalisieren Architektur der Debug/Trace Version der Winsock2-DLL Die Debug/Trace Version der Winsock2-DLL kommuniziert mit einer zusätzlichen DLL namens Dt_DLL (Dt steht für Debug/Trace). Die Schnittstelle zwischen beiden Modulen ist durch zwei Funktionen definiert, welche von der Dt_Dll exportiert werden. Diese Funktionen heißen WSAPreApiNotify und WSAPostApiNotify. Sie werden bei der Ausführung einer Funktion aus der Winsock2-DLL am Anfang und am Ende aufgerufen. Ruft eine Applikation eine beliebige Funktion aus der Winsock2-DLL, so ruft diese Funktion selbst WSAPreApiNotify aus der Dt_DLL, bevor etwas anders ausgeführt wird. Bei diesem Aufruf werden die Parameter mitgeliefert, mit denen die Winsock2-Funktion aufgerufen wurde, sowie zusätzliche Informationen über diesen Aufruf. Wenn die Ausführung der Winsock2-Funktion beendet ist, ruft sie als letztes WSAPostApiNotify auf. WSAPreApiNotify und WSAPostApiNotify werden auch ausgeführt, wenn die Winsock2 selbst eine Funktion aus einem Service Provider aufruft. Die Aufrufe von WSAPreApiNotify und WSAPostApiNotify bleiben für die Applikation unsichtbar. Abb. 7 ist aus der Dokumentation der Debug/Trace Version der Winsock2-DLL [25] übernommen und erklärt die Interaktion zwischen der Winsock2-DLL und Dt_Dll bei der Ausführung von connect. Die Funktionen WSAPreApiNotify und WSAPostApiNotify werden mit GetProcAddress gefunden. Falls sie nicht erreicht werden können, weil die Dt_Dll nicht gefunden wird oder weil die Dt_DLL diese Funktionen nicht exportiert, so läuft die Ausführung der jeweiligen Winsock2-Funktion ohne weiteres ab

23 WinSock 2 DLL 8 dt_dll.dll service provider 5 A typical execution path for WSAConnect involving the debug/trace layer is shown. (1) A client application calls WSAConnect. The WinSock 2 DLL calls the WSAPreApiNotify entry point in dt_dll.dll passing WSAConnect call information. The dt_dll.dll decodes the call info and returns. (2) The WinSock 2 DLL proceeds until it is about to call the provider. (3) The WinSock 2 DLL calls WSAPreApiNotify with WSPConnect call information. The dt_dll.dll decodes the information and returns. (4) The WinSock 2 DLL calls the service provider s WSPConnect function, which (5) performs the connect and returns. (6) The WinSock 2 DLL calls WSAPostApiNotify with WSPConnect call information. The dt_dll.dll decodes and returns. The WinSock 2 DLL completes its processing. (7) the WinSock 2 DLL calls WSAPostApiNotify with WSAConnect call information. The dt_dll.dll decodes and returns. (8) The WinSock 2 DLL returns the final result to the application. Abb.7: Typical execution through the debug/trace layer WSAPreApiNotify und WSAPostApiNotify Diese beiden Funktionen sind wie folgt definiert:

24 BOOL WINAPIV WSAPreApiNotify( IN INT NotificationCode, OUT LPVOID ReturnCode, IN LPSTR LibraryName,...); BOOL WINAPIV WSAPostApiNotify( IN INT NotificationCode, OUT LPVOID ReturnCode, IN LPSTR LibraryName,...); Listing 5.7: Die Prototypen von WSAPreApiNotify und WSAPostApiNotify. NotificationCode ist eine Integer-Zahl, welche die gerade aufgerufene Winsock2- Funktion kennzeichnet. Der Code der Winsock2-API- und -SPI-Funktionen ist in der Header-Datei Dt_Dll.H definiert. Bei einer neueren Version der Winsock kann dieser Code erweitert werden... #define DTCODE_accept 1 #define DTCODE_bind 2 #define DTCODE_closesocket 3.. #define DTCODE_socket 21.. Listing 5.8: Definition von NotificationCode in der Header-Datei von Dt_Dll. ReturnCode ist ein Pointer auf denjenigen Wert, der zurückgeliefert werden soll. Hier hat man die Möglichkeit bei WSAPostApiNotify diesen Wert zu lesen bzw. zu ändern. LibraryName ist der Name der verwendeten Bibliothek. Im Fall der API-Funktionen ist es die Winsock2. Im Fall der SPI-Funktionen ist es die Datei, in welcher der Service Provider implementiert ist. Schließlich kommt eine Parameterliste mit einer variablen Länge. Diese Liste enthält Pointer zu den Parametern, mit denen die Winsock2-Funktion aufgerufen wird. Die Extraktion der Parameter aus der Parameterliste wird später erklärt. Wie erwähnt, kann die Ausführung von Funktionen aus der Winsock2 den Applikationen vorgetäuscht werden. Das geschieht, indem man ReturnCode den gewünschten Rückgabewert zuweist und die Funktion WSAPreApiNotify mit der Rückgabe true beendet

25 Wenn WSAPreApiNotify true zurückliefert, wird die Ausführung der Winsock2 abgebrochen und der Wert zugeliefert, der von Returnvalue adressiert wird. Sonst wird die Funktion weiter ausgeführt. Das gleiche gilt für WSAPostApiNotify. In der Implementierung von connect sieht der Aufruf von WSAPreApiNotify etwa wie folgt aus. BOOL should_skip; int connect_return; should_skip = (* lpwsapreapinotify) ( DTCODE_connect, // NotificationCode (LPVOID) & connect_return, // ReturnCode winsock2.dll, // LibraryName & s, & name, & namelen); if (should_skip) { return(connect_return); } Listing 5.9: Implementierung von connect in der Debug/Trace Version der Winsock2-DLL. Somit erlaubt uns die Dt_Dll mit ihren Funktionen WSAPreApiNotify und WSAPostApiNotify volle Kontrolle über die Funktionsaufrufe an den API- und SPI- Schnittstellen. Rückgabewerte und Parameter können über ihre Pointer geändert werden und Funktionsaufrufe können abgelehnt werden. Jedoch möchten wir diese DLL nur verwenden, um Erkenntnisse über das Verhalten der Applikationen an der API- Schnittstelle zu gewinnen und werden diese Werte nicht ändern Implementierung An Hand von NotificationCode kann man erkennen, welche Funktion gerade aufgerufen wird und dementsprechend die Parameter von der Parameterliste extrahieren. Listing 5.10 erklärt dieses Verfahren an Hand des Beispiels der Funktion socket

26 BOOL WINAPIV WSAPreApiNotify(IN INT NotificationCode, OUT LPVOID ReturnCode, IN LPSTR LibraryName,...) { *LogFile << "\n" << NotificationCode << " + "; va_list vlist; // declare parameter list va_start(vlist, LibraryName); // initialize parameter list switch(notificationcode) { case DTCODE_socket: { int af = (int)*va_arg(vlist, int *); // extract parameter from parameter list int type = (int)*va_arg(vlist, int *); int protocol = (int)*va_arg(vlist, int *); *LogFile << "t " << type; break; } /* weitere case-anweisungen */ } return false; } // WSAPreApiNotify Listing 5.10: Implementierung von WSAPreApiNotify. Die Parameterliste va_list wird mit va_start initialisiert. Die einzelnen Argumente werden mit va_arg in der Reihenfolge aus der Liste extrahiert. Somit kann man alle Parameter auslesen, mit denen die Funktion socket aufgerufen wird. Hier folgt auch die Implementierung von WSAPostApiNotify für den Fall der Funktion socket

27 BOOL WINAPIV WSAPostApiNotify(IN INT NotificationCode, OUT LPVOID ReturnCode, IN LPSTR LibraryName,...) { *LogFile << "\n" << NotificationCode << " - "; va_list vlist; va_start(vlist, LibraryName); switch(notificationcode) { case DTCODE_socket: { SOCKET * s = (SOCKET *)ReturnCode; *LogFile << "s " << *s; // write the socket descriptor in the log file break; } /* weitere case-anweisungen */ } return false; } // WSAPostApiNotify Listing 5.11: Implementierung von WSAPostApiNotify. Hier wird der Parameter ReturnCode verwendet. Der Rückgabewert von socket ist ein Socket Descriptor. Dieser ist mit einem File Descriptor im Dateisystem vergleichbar. Nachdem das Socket abgelegt ist, kann der Socket Descriptor für die Ausführung von Send- und Receive-Befehlen und anderen Operationen verwendet werden. Wenn NotificationCode gleich DTCODE_socket ist, dann ist ReturnCode ein Pointer auf dem Socket Descriptor. Somit können dieser Wert gespeichert werden und nachfolgende Send- und Receive-Befehle jeweils ihren Sockets richtig zugeordnet werden. In der Windows Sockets 2 SDK befindet sich ein Beispiel für die Implementierung der Dt_DLL von Jeffrey C. Diese Implementierung vermeidet die Switch-Anweisung mit einem Aufruf von LOG-Funktionen über Pointer of functions, die dynamisch bestimmt werden. Mit diesem Ansatz kann man eine übergroße Switch-Anweisung vermeiden, wenn die Parameter mehrerer Funktionen protokolliert werden sollen. Schließlich können WSAPre- und WSAPostApiNotify mit 175 verschiedenen Werten von NotificationCode aufgerufen werden. Doch in unserer Implementierung wurde auf dieses elegante Verfahren verzichtet. Bei Jeffrey C. wird die Parameterliste va_list auf Grund ihrer variablen Länge mehrmals aufgeteilt und zusammengestellt, damit die Parameter zwischen Unterprogrammen weitergegeben werden können. Dieses Verfahren beeinflusst die Performance der Winsock2-DLL. Deshalb werden alle Fälle innerhalb von WSAPreApiNotify bzw. WSAPostApiNotify in einer Switch-Anweisung behandelt. Mit diesem einfachen Programmierstil ist unser Code auch nicht unübersichtlich geworden, zumal

28 wir uns auf wenige Winsock2-Funktionen beschränkt haben. In [25] wird der Ansatz von Jeffrey C. genauer beschrieben. 5.3 Zusammenfassung beider Ansätze Nachdem der zweite Ansatz vorgestellt wurde, stellt man fest, dass er bedeutend einfacher ist. Die Hauptaufgabe besteht darin, die zwei Funktionen WSAPre- und WSAPostApiNotify zu implementieren. Im ersten Ansatz umfasste der Quellcode der Winsock2-DLL über 2000 automatisch erzeugte Zeilen, nur um die Funktionen weiterzuleiten, und bevor weitere Logging-Funktionalität implementiert wird. Der Umfang der Implementierung von Dt_Dll hingegen umfaßt weniger als 400 Zeilen. Mit der Debug/Trace Version der Winsock2-DLL kann man auch einen Einblick in die Service Provider gewinnen, so dass das Verständnis der Funktionalität der Winsock2 gefördert wird. Außerdem ist die Dt_Dll mit einem neuen Betriebsystem einsatzbereit, sobald die passende Debug/Trace Version der Winsock2-DLL zur Verfügung steht. Die Dt_Dll wurde mit Windows 2000 implementiert. Die Debug/Trace Version der Winsock2 wurde aus der CD Microsoft Platform SDK, April 2001 übernommen. Sie wurde laut Microsoft-Angaben mit der Beta-Version von Windows XP getestet. 6. Daten erfassen und visualisieren Nachdem wir einen Eingangspunkt in die Winsock2-DLL implementiert und ein Verfahren realisiert haben, mit dem wir von den Funktionsaufrufen aus der Winsock2- DLL benachrichtigt werden und auf die Parameter zugreifen können, mit denen diese Funktionen aufgerufen werden, möchten wir diese Ereignisse visualisieren bzw. in Dateien protokollieren und auswerten. Unser Ziel ist, das Verhalten der Applikation an der API-Schnittstelle zu untersuchen. Insbesondere sind einige Informationen relevant für die Analyse dieses Verhaltens, z.b. die Lebensdauer eines Sockets, die Zeitspanne zwischen zwei Send- oder Receive- Befehlen und die Paketgröße. Eventuell können sich nachträglich weitere Informationen als relevant erweisen. 6.1 Winsock2-API-Monitor Um die Daten zu visualisieren, sind einige Möglichkeiten denkbar. Erwünscht wäre z.b. ein Monitor, der die Aufrufe von Funktionen aus der Winsock2-DLL mit ihren Parametern unmittelbar und in Echtzeit anzeigt 4. Doch die Leistung der CPU wird durch die unverzögerte Ausgabe der Funktionsaufrufe mit ihren Parametern stark beeinträchtigt. Die Ausführung der Kommunikationsbefehle wird gebremst. Applikationen, die Echtzeit- Anforderungen haben, wie Multimedia-Übertragung bspw. Voice Over IP, werden 4 Vgl. den API-Monitor von TracePlus. In der Homepage von SST Inc. wird behauptet, dass TracePlus echtzeitfähig sei. Dies ist allerdings zu bezweifeln

29 nicht mehr echtzeitfähig. Außerdem werden die Messwerte der Zeitspannen nicht mehr aussagekräftig, wenn ein großer Teil der Ausführung der Kommunikationsbefehle in der Ausgabe, und nicht in der eigentlichen Ausführung des Befehls vergeht. 6.2 Performance Monitor Der Performance Monitor (Perfmon.exe) ist ein Feature von Windows NT/2000, mit dem mehrere Systemeigenschaften wie Prozessorleistung, Netzwerkverkehr, Dienste und Treiber visualisiert und analysiert werden können. Die Daten, die der Performance Monitor visualisieren kann, sind so genannte Counter. In der Registry stehen Einträge für die existierenden Counter und jeweils eine DLL, mit der die Counter berechnet werden können. Diese DLL wird von dem Prozess PerfMon.exe geladen und muss drei Funktionen exportieren: Open, Collect und Close. Die Counter werden mit Collect in regelmäßigen Zeitabständen gelesen und auf dem Performance Monitor visualisiert. Die Größe eines Pakets beim Senden oder Empfangen kann mit dem Performance Monitor visualisiert werden, wenn sie in einem Array gespeichert wird und der Prozess PerfMon.exe diese Daten über eine DLL lesen kann. Diese DLL muss die Funktionen Open, Collect und Close exportieren. Dies ist unabhängig davon, welcher Ansatz bei dem Zugriff auf die Daten implementiert wird. Beim ersten Ansatz würde die neue Winsock2- DLL zusätzlich zu den üblichen Winsock2-Funktionen die drei Funktionen Open, Collect und Close exportieren. Beim zweiten Ansatz würden diese drei Funktionen von der Dt_Dll zusätzlich zu WSAPre- und WSAPostApiNotify exportiert werden. Der Performance Monitor und die Applikation müssen sich einen gemeinsamen Speicherbereich teilen, in dem diese Daten gelesen bzw. geschrieben werden. Mit dem in Abschnitt vorgestellten Verfahren Memory Sharing kann sich der Performance Monitor die Daten mit einer Applikation teilen. Somit können diese Daten mit dem Performance Monitor visualisiert werden. Doch dieses Verfahren erfordert eine aufwändige Synchronisation des Zugriffs auf das gemeinsame Daten-Segment, denn die Daten werden für andere Prozesse blockiert, wenn ein Prozess auf sie zugreift. Der Performance Monitor und die jenige Applikation würden sich gegenseitig stören. Diese Synchronisation würde die Ausführung der Kommunikationsbefehle öfter blockieren. Damit ist eine aussagekräftige Visualisierung der Daten durch den Performance Monitor nicht möglich. 6.3 LOG-Datei Nachdem die Nachteile des Winsock2-API-Monitors und des Performance Monitors vorgestellt wurden, bleibt uns nur eine Möglichkeit, das Verhalten der Applikation an der API-Schnittstelle zu kontrollieren: Die Daten werden in einer Log-Datei gespeichert und sämtliche unmittelbaren Ausgaben auf dem Bildschirm vermieden. Selbst die Ausgaben in der Datei müssen möglichst gering bleiben. Hier kommt uns der NotoficationCode von

30 der Debug/Trace Version der Winsock2-DLL zugute: Eine kleine Zahl in die Datei zu schreiben, ist viel effizienter als den ganzen Namen der Funktion zu schreiben. Die LOG- Datei kann nachträglich mit einem Perl-Script dekodiert werden Ausgabe der LOG-Dateien Listing 6.1 zeigt einen Abschnitt einer LOG-Datei, die mit der Ausführung von Internet Explorer erzeugt wurde. % Winsock API Log File % Module: E:\Program Files\Internet Explorer\IEXPLORE.EXE % Node: ALADIN % Initiated: , 15:6:12 % Frequency % Start t s s 736 l % Performance factor: % Listing 6.1: Ausschnitt einer Winsock2-API-LOG-Datei. Die Zeilen, die mit dem Zeichen % anfangen, geben allgemeine Informationen über den gesamten Prozess, z.b. Modul-Name, NetBIOS-Name des Knoten und die Uhrzeit, zu der Winsock2 DLL geladen wird. Beim Aufruf von WSAPre bzw. WSAPostApiNotify wird der NotificationCode der jeweiligen Funktion in die LOG-Datei geschrieben. Das Zeichen + steht dafür, dass die Funktion aufgerufen wird, und - steht dafür, dass sie beendet wird. Danach kommt ein Counter der Zeit in hoher Genauigkeit. Dieser Counter wird mit dem Befehl QueryPerformanceCounter hardwarenah gemessen. Dieser Befehl wird nicht von jeder Hardware unterstützt. Der Befehl QueryPerformanceFrequency gibt an, wie oft in einer Sekunde dieser Counter inkrementiert wird. Wenn z.b. diese Frequenz in der Größenordnung von 10 6 ist, dann ist die Genauigkeit des Counters im Bereich von Mikrosekunden. Die Frequenz wird am Anfang gemessen und in die Datei ausgegeben, damit sie später für die Übersetzung des Counters in natürliche Zeiteinheiten verwendet

31 wird. Der Counter Start gibt den Zeitpunkt an, an dem die Winsock2-DLL geladen wird. So wird später die relative Zeit am Startpunkt berechnet. Zusätzlich dazu kommt bei einigen Funktionen die Ausgabe von wichtigen Parametern. So wird z.b. beim Aufruf von socket (NotificationCode = 21) protokolliert, welchen Typ von Socket die Applikation wünscht. Die gängigsten Socket-Typen sind TCP (type = 1) und UDP (type = 2). Beim Beenden von socket wird der Rückgabewert, also der Socket Descriptor, gespeichert. Bei Send- und Receive-Befehlen wird die Länge des Pakets gespeichert. Damit die Syntaxanalyse der LOG-Datei später vereinfacht wird, steht vor diesen Zahlen jeweils ein Zeichen, das erklärt, welche Bedeutung diese Zahl hat. Unter anderem steht s für den Socket Descriptor, t für den Typ des Sockets und l für die Länge des Pakets Performance Factor Zum Schluss der LOG-Datei kommt der Performance factor : der Anteil der Ausführung der Logging-Befehle zu der gesamten Ausführung des Winsock2-Befehls in Prozent. Die Zeit zum Schreiben in die Datei und die Zeit zur Ausführung des gesamten Befehls wird bei jeder Winsock2-Operation mit dem Befehl QueryPerformanceCounter gelesen und addiert. Zum Schluss wird der durchschnittliche Anteil in Prozent ausgerechnet. Der Performance Factor entspricht dem Einfluss der Protokollierung der erforderlichen Daten auf die Ausführung der Winsock2-Funktionsaufrufe. Er variiert nach Applikation und Hardware. Bei einer CPU mit 466 MHZ Taktfrequenz und 128 MB RAM bleibt der Performance Factor bei Internet Explorer meistens unter 1%. Bei anderen Applikationen wie Netscape steigt er leider manchmal bis 33%. Die Daten könnten in einem statischen Array gespeichert werden und erst innerhalb eines Threads niedriger Priorität vom Array zu der Datei kopiert werden. Dies macht allerdings das Logging nicht schneller. Zeitmessungen weisen nach, dass der Zugriff auf ein statisches Array innerhalb von WSAPre- oder WSAPostApiNotify nicht schneller ist als der Zugriff auf eine Datei. Das parallele Thread würde trotz seiner niedrigen Priorität den Prozess nur langsamer machen. Die aufwändige Entwicklung eines solchen Verfahrens ist die Mühe nicht Wert. Die Daten werden mit einfachen Schreib-Befehle in die Datei geschrieben. *LogFile << NotificationCode << " + "; Übersetzung der LOG-Datei Die Log-Dateien können auf zwei verschiedenen Arten mit Perl-Scripten dekodiert und interpretiert werden. Ein Script namens Ws2_API.pl übersetzt einfach jeweils den