Konzeption und prototypische Implementierung eines Generators für heterogenen Netzwerktraffic unter dem Aspekt des Einsatzes in Forschung und Lehre

Transkript

1 Konzeption und prototypische Implementierung eines Generators für heterogenen Netzwerktraffic unter dem Aspekt des Einsatzes in Forschung und Lehre Diplomarbeit vorgelegt von Andreas Leibrock Prüfer: Prof. Dr. Hans-Jürgen Steffens Zweitprüfer: Prof. Dr.-Ing. Manuel Duque-Antón Fachbereich I/MST Fachhochschule Kaiserslautern Standort Zweibrücken 27. September 2005

2 c Copyright 2005 Andreas Leibrock Alle Rechte vorbehalten

3 Ehrenwörtliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Limbach, am 27. September 2005 Andreas Leibrock i

4 ii

5 Kurzfassung In einem Labor für Rechnernetze soll unter anderem den Studenten ein Einblick in die Struktur moderner Netzwerke gegeben werden. Hierzu ist es in der Regel erforderlich, dass die Studenten bestehenden Netzwerktraffic analysieren können. Hier stellt sich dem Lehrbetrieb jedoch ein Problem: Wie erhalte ich genau den Traffic, den die Lernenden untersuchen sollen. Aus diesem Grund braucht man eine Software, welche - durch einfache Eingabeparameter gesteuert - den Traffic erzeugt, der im Labor erwünscht ist. Eine solche Software wird prototypisch im Rahmen dieser Arbeit entwickelt. iii

6

7 Nomenklatur Um die Lesbarkeit des Programmtextes zu verbessern, wurde eine Nomenklatur eingeführt. Diese soll auch bei der Weiterentwicklung der Module Verwendung finden. Allgemeines Variablennamen beginnen mit dem ersten Buchstaben des Typs (int ifoo- Bar). Zusammengesetzte Namen : Das neue Wort beginnt mit einem Grossbuchstaben (diesisteinnameeinerneuenvariablenoderfunktion). Klassen Klassennamen beginnen immer mit einem C (Bsp: CKlasse). private Attribute beginnen mit einem Unterstrich (Bsp: int iattribut). Prefixe globale Funktionen/Methoden die alle Plugins betreffen: P (Bsp: P Main) protokollspezifische Module: Proto (Bsp: Proto FTP) Grafiken Auch in den Grafiken wird ein einheitliches System von Symbolen aufrechterhalten. v

8 Symbol Bedeutung Datum1 next Knoten einer einfach verketteten Liste prev Datum2 next Knoten einer doppelt verketteten Liste Datum 3 Zeiger Nomenklatur Symbole UML Auch bei der UML-Darstellung wurde darauf geachtet, dass die gängigen Notationen eingehalten wurden. CKlasse # iprotectedattribut : int + cpublicattribut : char - bprivateattribut : bool +CKlasse() + CKlasse() +publicfunktion(parameter) : void #protectedfunktion(parameter) : void - privatefunktion(parameter) : void Prototyp einer UML-Klasse

9 Akteur1 Use Case 1 uses Akteur2 Use Case 3 Use Case 2 USE CASE- Diagramm Prototyp eines Use-Case-Diagramms Listings Quelltexte werden im laufenden Text wie folgt dargestellt: 1 2 /* */ 3 //Dies ist ein Listing 4 5 int test(char* foo){ 6 cout << foo << endl; 7 return 0; 8 } Listing 1: Prototyp Listing Es wird eine farbliche Hervorhebung vorgenommen. Hierbei werden Kommentare in Blau und Operatoren in Grün eingefätbt. Programme Als Programme werden im Folgenden Abdrucke von Sitzungen bezeichnet. Wird auf der Kommandozeile des Betriebsystems (Shell) ein Kommando ausgeführt, so wird dies folgendermassen im Text präsentiert:

10 pwd /home/leibi lsof -i COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nuts 4899 leibi 5u IPv TCP *:9999 (LISTEN) prototypische Programmsitzung Man sieht in Zeile eins und drei die Eingabeaufforderung des Betriebsystems. Im ersten Fall wird der Befehl pwd abgesetzt, welcher das aktuelle Arbeitsverzeichnis anzeigt. Dies sieht man in Zeile zwei. Der Befehl lsof -i in Zeile drei gibt an, welche Programme gerade an einer Netzwerkschnittstelle aktiv sind. An dieser Stelle sieht man das Programm nuts, welches an Port 9999 auf jeder verfügbaren Schnittstelle lauscht. Nuts ist der Arbeitsname für das hier entwickelte Programm. Das Akronym steht für N etwork U ser T raffic S imulator, also die Simulation von durch Benutzer erzeugten Netzwerkverkehr. Da in der Entwicklung klar geworden ist, dass es sich mehr um einen Generator denn um einen Simulator handelt, ist der Name noch verbesserungsfähig. Da der Name jedoch schon vor Beginn dieser Arbeit bestand, wird er noch beibehalten.

11 Inhaltsverzeichnis 1 Einführung Danksagung Motivation Schon vorhandene Generatoren Ausstattung des Labors Grundlagen Produktionssystem Programmiersprachen Dynamisches Laden von Modulen Auswerten der Übergabeparameter Einlesen der Konfigurationsdatei Designentscheidungen Programmierparadigma Threads oder Prozesse Softwareengineering Planung Abschliessende Prüfungen Analyse ix

12 INHALTSVERZEICHNIS 5 Der Kern Verwaltung der Module Kommunikation - Grundlagen Kommunikation Implementierung Plugins Verbindliche Funktionen Laden der Module Die Module Entwicklung eigener Module Die Hilfsdateien Das Makefile Konfiguration Konfigurationsdateien Netzwerkschnittstelle Installation Quellcode Debian Package Debian Paket erstellen Lizenz Testen Betriebsysteme Plattformen Fazit und Ausblick 111 A Datentypen 113 A.1 Der Datentyp Verkettete Liste x

13 INHALTSVERZEICHNIS B Hilfsfunktionen strukturierter Prototyp 119 B.1 Listnode mknode() B.2 Listnode GetNodeByName B.3 void RenumberList B.4 void ShowPlugins() B.5 usage B.6 getoptions B.7 getconfig C Hilfsfunktionen für die Plugins 125 C.1 write to pipe C.2 read from pipe D Inhalt der CD-Rom 127 E Verzeichnisse 131 Abbildungen Tabellen Listings Programme UML-Diagramme Glossar Literatur Stichworte xi

14

15 KAPITEL EINS Einführung The White Rabbit put on his spectacles. Where shall I begin, please your Majesty? he asked. Begin at the beginning,, the King said, very gravely, and go on till you come to the end: then stop. Lewis Carroll 1.1 Danksagung Ich möchte mich in aller Form bei all denen bedanken, die diese Diplomarbeit möglich gemacht haben. An erster Stelle sind hier meine Eltern, Axel und Doris Leibrock zu nennen. Sie haben mir mein Studium ermöglicht und mich immer ideel und finanziell stark unterstützt. Einen besonderen Dank möchte ich Jan Dworschak aussprechen, der mir mit Kaffee, guten Ratschlägen und Korrekturvorschlägen sehr geholfen hat. Grossen Dank gebührt auch Herrn Prof. Dr. Steffens, der mir die Möglichkeit gab, diese Diplomarbeit umzusetzen. Und zuletzt, aber sicher nicht mit der geringsten Bedeutung, ist hier Herr Dipl-Inf. Oliver Keller zu nennen. Er hat mich während der Arbeit immer mit Rat und Tat unterstützt und vor allem im Bereich der Netzwerktechnik stand er immer mit einer hilfreichen Bemerkung zur Seite. 1

16 MOTIVATION 1.2 Motivation Im Rahmen vieler Laborumgebungen im Bereich Netzwerke und Telekommunikation stehen Rechner zur Verfügung, an denen die Teilnehmer Netzwerkverkehr beobachten können, um daran zu lernen. Das Problem hierbei ist, dass nicht immer genau der Traffic zur Verfügung steht, der auch erwünscht ist. Das Ziel dieser Diplomarbeit ist es, dieses Manko zu beseitigen. Durch den Generator, der im Rahmen dieser Arbeit entsteht, kann der Übungsleiter dynamisch Netzwerkverkehr erzeugen lassen, der genau auf seine Bedürfnisse zugeschnitten ist. Um so viele Anforderungen wie möglich erfüllen zu können, muss der Generator sehr modular aufgebaut sein. So können auch noch nach Abschluss dieser Arbeit Module entwickelt und eingebunden werden. Es soll also nachher ein relativ kompakter Kern vorhanden sein, der als Hauptaufgabe die Module verwaltet. Die Funktionalität wiederum ist in den Modulen realisiert Da im Labor für Rechnernetze und Telekommunikation der Fachhochschule ein Routing-Cluster zum Einsatz kommen soll, dessen Knoten unter Linux und/oder OpenBSD laufen, muss die Software unter Linux funktionieren und getestet werden. Eine spätere Portierung nach OpenBSD ist nicht ausgeschlossen. Deswegen wird auf POSIX-Konformität geachtet. Aber nicht nur die Lauffähigkeit unter Linux ist entscheidend. Da im Rahmen der FH Module für den Generator entwickelt werden sollen, muss die Software unter einer freien 1 Lizenz 2 zur Verfügung gestellt werden. Wichtig ist hier, dass der Begriff Netzwerktraffic nicht auf Pakete der Protokolle der OSI-Schichten zwei bis vier beschränkt wird. Auch und vor allem Protokolle höherer Schichten sind in einem Labor dieser Art von Interesse. Beispielhaft seien hier HTTP, SMTP und POP3 genannt. Genaueres zum Aufbau des OSI-Modells ist dem Buch von Tanenbaum [Tan00] zu entnehmen. 1 Im Sinne von 2 GPL, siehe Kapitel 8.4

17 KAPITEL 1. EINFÜHRUNG Schon vorhandene Generatoren Zu Beginn der Arbeit gilt es zu prüfen, ob es schon Software gibt, welche die Anforderungen des Labors erfüllt. Somit wäre keine Eigenentwicklung erforderlich oder es könnte eine bestehende Software weiterentwickelt werden. Eine Suche im Internet nach dem Begriff Traffic Generator führt zu mehreren Millionen Ergebnissen. Daraus gilt es nun Projekte zu finden, welche zu den Anforderungen passen. Neben offensichtlichen Fehlergebnissen wie zum Beispiel und welche anbieten Traffic für die eigene Homepage zu erzeugen um damit Besucher zu simulieren, findet man auch einige Projekte, welche dem Ziel der Suche näher kommen. Diese kann man grob in freie und kommerzielle Projekte unterteilen. Eine Auswahl freier Projekte sieht man in Tabelle 1.1. Projekt Distributed Internet Traffic Generator Real-Time Voice Traffic Generator Network Traffic Generator Mtools IP packets generator(ipgen) The Packet Shell Web-Präsenz msamidi/ projects.htm Tabelle 1.1: freie Projekte zur Erzeugung von Netzwerktraffic Obwohl die Zahl der Projekte, welche sich mit der Erzeugung von Netzwerkverkehr beschäftigen relativ gross ist, ist ihre Ausrichtung relativ gleich gerichtet. Die unteren vier Projekte aus Tabelle 1.1 sind nur in der Lage, Protokolle der OSI-Schichten drei und vier zu erzeugen. Dies ist auch verständlich, denn das Ziel dieser Generatoren ist es, das Netzwerk zu sättigen und so eine Auslastung zu erzeugen. Dies erreicht man am einfachsten mit primitiven Paketen. Deswegen sind die am häufigsten realisierten Protokolle IP und UDP. Einzig IpGen und Packet Shell sind in der Lage auch ICMP-Pakete zu generieren. Im Falle der Packet Shell sogar für IPv6. Wie der Name schon sagt, wurde der Real-Time Voice Traffic Generator dafür entwickelt, Sprachdaten zu erzeugen. Er bedient sich hierzu einfacher UDP-Pakete, welche er entsprechend anpasst. Dieses Projekt simuliert damit zwar eine höhere Schicht, erzeugt aber nur Pakete der niedrigen. Des

18 SCHON VORHANDENE GENERATOREN Weiteren ist das Projekt durch seine Zielsetzung unflexibel und somit für den Einsatz im Labor nicht geeignet. Das Projekt D-ITG (Distributed Internet Traffic Generator) der Universita degli Studi di Napoli Federico II ist das Einzige, welches den Verkehr, welchen es erzeugen soll, durch stochastische Methoden berechnen kann. Das Projekt ist auf Linux und Windows lauffähig, multithreaded und unterstützt die Protokolle TCP, UDP, ICMP, DNS, Telnet, VoIP (G.711, G.723, G.729, Voice Activity Detection, Compressed RTP). Eine Unterstützung weiterer Protokolle (unter anderem SMTP, HTTP, FTP) ist geplant, aber noch nicht realisiert. Leider ist diese Unterstüztung nicht durch ein modulbasiertes System verwirklicht, so dass ein einfaches Nachladen neuer Funktionalitäten nicht möglich zu sein scheint. Dies zeigte eine Analyse des Quellcodes, welcher unter ITG/codice/D-ITG-2.4.zip zur Verfügung steht. Auch wenn in der Motivation erklärt wurde, dass die Software frei sein muss, lohnt es sich im Vorfeld einen Blick auf die kommerziellen Produkte zu werfen, um deren Leistungsfähigkeit einschätzen zu können. Projekt ZTI: IP Traffic - Test & Measure WAN Killer SiteSpy Candela Technologies LANforge-FIRE Network Traffic Generator Web-Präsenz iptraffic-test-measure.htm Miscellaneous/WAN%20Killer/index.htm SiteSpy/SiteSpy.asp lab/network traffic generation/index.cfm Tabelle 1.2: kommerzielle Projekte zur Erzeugung von Netzwerktraffic Leider bedeutet kommerziell nicht unbedingt, dass der Funktionsumfang dem geforderten nahe kommt. Beim ersten Kandidaten ZTI: IP Traffic - Test & Measure fällt gleich auf, dass diese Software nur unter Micosoft Windows einsetzbar ist. Insofern erfüllt sie die Anforderungen des Labors nicht. Zudem kann nur IP-Traffic erzeugt werden. ZIT macht Werbung mit der Aussage, dass IP Traffic is independent of any transmission or telecom link and can use any transmission link managed by the Windows operating system. Dies ist jedoch nicht anders zu erwarten, denn warum sollte eine Software eine vom Betriebsystem bereitgestellte Schnittstelle nicht nutzen können? Der WAN Killer der Firma Solarwinds.net ist ein Vertreter der klassischen

19 KAPITEL 1. EINFÜHRUNG 5 Sättigungstools. Mit ihm kann die Auslastung in vier Schritten (Zitat: 25% 50% 100% or even 150%! ) gesteuert werden. Wie auch immer eine Auslastung von 150 % erreicht wird. Darüber wird leider nicht informiert. Da aber auch hier auf Windows gesetzt wird und keine Module selbst beigesteuert werden können, ist auch diese Software keine Alternative. Die Software SiteSpy schliesst auch kabellose Verbindungen ein. Laut Aussagen des Herstellers Wirelessvalley ist sie besonders für IEEE a/b/g, HomeRF, HiperLAN, or Bluetooth wireless, wired or hybrid networks geeignet. Der Schwerpunkt liegt jedoch laut Homepage auf W-LAN (IEEE a/b/g). Wieder wird hier die Auslastung des Netzwerks als Ziel der Traffic-Erzeugung gesehen. Auch dieses Tool ist zur Planung und zum Test eines neuen Netzwerks geeignet. Zur Erzeugung beliebigen Verkehrs im Sinne der Lehre und Forschung ist es jedoch ungeeignet. Im Leistungsumfang sticht das Produkt LANforge-FIRE Network Traffic Generator der Firma Candela Technologies heraus. Die Erzeugung der verbreitetsten Protokolle wie zum Beispiel FTP, HTTP, VoIP (SIP, RTP, RT- CP), TCP, UDP oder auch Ethernet-Frames ist möglich. Die Software läuft unter Linux und kommt damit den Anforderungen des Labors bisher am nächsten. Leider ist der Quellcode nicht verfügbar und die Erzeugung eigener Module nicht möglich. Somit ist man in der Weiterentwicklung auf die Firma Candela Technologies angewiesen. Fazit Im Bereich der Erzeugung von Netzwerktraffic gibt es vielfältige Projekte. Aber der für das Labor interessante Bereich der höheren Schichten des OSI- Modells wird nur sehr sparsam abgedeckt. Die meisten Generatoren sind für Netzwerktests entwickelt und beschränken sich deswegen auf IP, sowie TCP und/oder UDP. Um ein Netzwerk zu sättigen ist dies zwar die beste Strategie, jedoch ist die Zielsetzung dieser Diplomarbeit eine andere. Einzig ein kommerzielles Produkt deckt diesen Bereich ausreichend ab. Doch hier sind der fehlende Quellcode, und damit die fehlende Möglichkeit der Weiterentwicklung durch Studenten der FH, und die kommerziellen Motive des Herstellers Punkte, die gegen den Einsatz der Software sprechen.

20 AUSSTATTUNG DES LABORS 1.4 Ausstattung des Labors Im Labor für Rechnernetze und Telekommunikation der FH Kaiserslautern, Standort Zweibrücken stehen folgenden Rechner zur Verfügung: Anzahl Rechner 7 AMD Athlon 900 Mhz, 256 MB RAM, 20 GB Festplatte, Windows XP 7 Intel Pentium II 350 MHz, 256 MB RAM, 4 GB Festplatte, Debian GNU/Linux 7 AMD Athlon 800 MHz, 256 MB RAM, 8 GB Festplatte, Windows XP 5 Intel Pentium-MMX 200 MHz, 320 MB RAM, ohne Festplatte, Fli4L 2 Intel Pentium-S 100 MHz, 32 MB RAM, ohne Festplatte, Fli4L Tabelle 1.3: Ausstattung Labor Es stehen sieben Arbeitsplätze mit je vier Rechnern für die Studenten bereit. Die in dieser Arbeit entwickelte Software soll auf den Pentium-II-Rechnern mit Debian GNU/Linux eingesetzt werden. Als Infrastruktur steht eine vollständige Verkabelung der Arbeitsplätze bereit. Diese läuft auf ein Patchfeld im Büro des Assistenten zusammen. Dort stehen auch Cisco-Router und Switches, um die Arbeitsplätze den Anforderungen entsprechend zu verkabeln. Zusätzlich steht pro Arbeitstisch ein Switch zur Verfügung, der eine lokale Verkabelung erlaubt.

21 KAPITEL ZWEI Grundlagen Wer hohe Türme bauen will, muß lange beim Fundament verweilen. Dr. h.c. Anton Bruckner In diesem Kapitel wird erläutert, auf welchem System diese Diplomarbeit entstand und auf welche Art und Weise diese Arbeit gelesen werden sollte. Hierzu gehört die Nomenklatur, welche durchgehend verwendet wird. Aber auch die benutzten graphischen Symbole werden erklärt, um Missverständnisse zu vermeiden. Zudem werden die technischen Grundlagen erläutert, welche unabhängig von den Entscheidungen in Kapitel 3 (Designentscheidungen) verwendet werden. Zu diesen gehört die Art und Weise wie Module während der Laufzeit nachgeladen werden. Weitere Punkte sind das Auswerten der Übergabeparameter und das Einlesen der Konfigurationsdatei. 2.1 Produktionssystem Da das System, wie in Kapitel 1.2 beschrieben, unter Linux entwickelt und getestet wurde, ist als Produktionssystem im Labor der Laptop des Autors mit Debian GNU/Linux eingesetzt worden. Als Compiler wurde der g++ aus der Gnu Compiler Collection (GCC) 1 in Version eingesetzt. Als Hilfe beim Übersetzen wurde GNU make benutzt

22 PROGRAMMIERSPRACHEN Tests unter weiteren Systemen und mit anderen Konfigurationen werden in Kapitel 9 beschrieben. 2.2 Programmiersprachen In die engere Auswahl kamen nur Sprachen, welche auf den oben genannten Systemen eine weite Verbreitung erfahren haben. Somit fiel die Wahl auf C und C++. Java wurde als Interpretersprache von vornherein ausgeschlossen. Zwar ist auch hier Netzwerkprogrammierung möglich, jedoch ist die Verbreitung oben genannter Sprachen grösser. Somit kann man sich auf eine breitere Basis stützen und schon vorhandene Bibliotheken und Implementierungen nutzen, falls dies nötig sein sollte. Die genaue Wahl der Programmiersprache fällt in Kapitel Designentscheidungen. 2.3 Dynamisches Laden von Modulen Ein wesentlicher Punkt bei der Generatorsoftware ist die Modularisierung. Die Module sollen zur Laufzeit des Hauptprogramms dynamisch geladen werden. Die Technik dafür stellen die Funktionen dlopen und dlsym bereit. Da diese Technik unabhängig von der Wahl der Programmiersprache verwendet wird und bei C und C++ identisch ist, wird sie schon an dieser Stelle vorgestellt und nicht erst in der Entwurfsphase des Softwareengineering-Prozesses. Bei den oben genannten Funktionen handelt es sich um die Schnittstellen zum dynamic linking loader. Dieser stellt die Möglichkeit bereit, Symbole aus Bibliotheken dynamisch zu laden, ohne das Programm gegen diese Bibliotheken zu linken. Will man Symbole (zum Beispiel Funktionen) aus Bibliotheken in einem Programm nutzen ist es der übliche Weg, das Programm nach dem Übersetzen statisch oder dynamisch gegen diese Bibliothek zu linken. Es ist jedoch nicht davon auszugehen, dass alle Module schon beim Übersetzen des Kerns bereit stehen. Viel mehr ist es wahrscheinlich, dass später neue Module hinzukommen. Aus diesem Grund ist es notwendig, die Funktionen aus den Modulen (welche später als Bibliotheken realisiert werden) dynamisch verfügbar machen zu können, ohne den Kern neu zu linken.

23 KAPITEL 2. GRUNDLAGEN 9 Um das Prinzip der Symbole genauer zu verstehen ist in Listing 2.1 ein Auszug der Symbole des Kerns dargestellt. Die vollständige Liste lässt sich unter GNU/Linux mit dem Befehl nm <programmdatei> ausgeben a198 T _ZN5CList10getCounterEv a1a4 T _ZN5CList10setCounterEi c64 T _ZN7CPlugin10cPrintListEv f94 W _ZN7CPlugin10getVersionEv ba8 W _ZN7CPlugin10setVersionEPc Listing 2.1: Auszug der Symbolliste des Kerns Man sieht hier den Wert des Symbols in hexadezimaler Darstellung, den Typ und den Namen des Symbols. Bei den Typen steht T dafür, dass das Symbol in der Code-Sektion der Objektdatei steht und W, dass dies ein schwaches Symbol (weak symbol) ist. Wenn ein schwaches Symbol, welches gegen eine regulät definierte Funktion gelinked wurde, so wird diese Funktion ohne Fehler ausgeführt. Sollte die Definition nicht erfolgreich gewesen sein, wäre der Wert des Symbols auf Null geändert worden. In obigem Beispiel wäre eine solche Funktion die Methode getversion der Klasse CPlugin. Dieses Symbol ist hier als schwach bezeichnet, weil die Funktion inline implementiert wurde. Um Symbole nun dynamisch nachladen zu können, kommen die weiter oben genannten Funktionen ins Spiel dlopen Syntax: void *dlopen(const char *filename, int flag); Diese Funktion lädt die dynamische Bibliothek, welche durch den String in filename übergeben wurde. Dieser String enthält den Namen der Datei, welche geladen werden soll. Beginnt dieser String mit einem Slash (/), so wird er als absoluter Pfad gewertet. Ansonsten wird anhand der Parameter von ld (dem Loader für dynamische Bibliotheken) verfahren. Hierzu findet sich mehr in der Man-Page von ld.so 3. Der Parameter flag bestimmt, zu welchem Zeitpunkt die Symbolnamen aufgelöst werden sollen. RTLD NOW besagt, dass alle bisher nicht aufgelösten Symbolnamen aufgelöst werden müssen, bevor dlopen() zurückkehrt. 3 man 8 ld.so

24 DYNAMISCHES LADEN VON MODULEN RTLD LAZY besagt, dass die Symbolnamen erst aufgelöst werden, wenn dies wirklich nötig ist. Als Rückgabewert gibt dlopen() einen void-zeiger als Handler zurück. Falls filename NULL sein sollte, zeigt der Handler auf main. Im Fehlerfall gibt dlopen() NULL zurück dlclose Syntax: int dlclose(void *handle); dlclose() dient zum Schließen der per dlopen() geöffneten Bibliothek. Dazu nimmt sie das passende Handle als Parameter. Sie gibt bei Erfolg 0 zurück. Bei Nichterfolg einen Wert ungleich Null dlsym Mittels der Funktion dlsym() werden die Symbole aus der geöffneten Bibliotheksdatei geladen. Syntax: void *dlsym(void *handle, const char *symbol); Die Funktion nimmt den von dlopen() zurückgegebenen Handler und einen String mit dem zu ladenden Symbolnamen. Ist das Laden des Symbols erfolgreich, gibt dlsym() die Adresse des Symbols im Speicher zurück. Ist das Laden nicht erfolgreich, so wird NULL zurückgegeben. Allerdings könnte die Adresse eines Symbols tatsächlich NULL sein. So braucht man einen Weg um sicherzugehen, ob ein Fehler aufgetreten ist. Die Funktion dlerror() stellt einen solche Funktionalität bereit dlerror Syntax: char *dlerror(void);

25 KAPITEL 2. GRUNDLAGEN 11 dlerror() gibt einen String zurück, in dem im Klartext der letzte Fehler beschrieben wird, der bei einer der dl-funktionen (dlopen, dlsym, dlclose) aufgetreten ist Beispiel Hier wird anhand eines einfachen Beispiels gezeigt, wie eine Funktion ausgelagert und dynamisch während der Laufzeit dazugeladen wird. Zunächst wird die zu ladende Funktion, in diesem Beispiel die Funktion test() implementiert. 1 int test(){ 2 puts("hallo, dies ist die Testfunktion."); 3 return 103; 4 } Listing 2.2: dynamic linking Beispiel: test.c Der Quellcode wird nun übersetzt und gelinked, damit eine Bibliotheksdatei entsteht. Dieses kann später geladen werden. gcc -fpic -shared -o test.so test.c Hierdurch erhält man die Bibliotheksdatei test.so. Der Parameter fpic bewirkt, dass der Compiler Position Indipendend Code erzeugt. Dies bedeutet, dass relative statt absoluter Adressen im Speicher benutzt werden. Damit können diese Bibliotheken auch mehrfach geladen werden. Mit der Option shared wird eingestellt, dass die Bibliothek plattformunabhängig bleibt. Nun zum Hauptprogramm, in dem das Laden stattfindet. Dieses sieht man in Listing 2.3. Hier werden die obigen Funktionen angewandt. Um sie nutzen zu können, wird der Header dlfcn.h eingebunden. Als Erstes werden die Variablen und Typen deklariert, welche später benötigt werden. Wie oben gesehen, gibt dlopen() einen void* zurück. Dieses handle wird - wie nicht anders zu erwarten - in der Variablen handle gespeichert (Zeile 6). Da von dlsym() eine Adresse zurückkommt, nachher aber eine Funktion aufgerufen werden soll, muss ein entsprechender Cast ausgeführt werden. Dazu hilft die Definition eines Hilfstyps intfunc t (Zeile 8). Nun wird die Bibliothek geöffnet (Zeile 11) und damit auch das handle gefüllt. Durch die nachfolgende Fehlerbehandlung wird sichergestellt, dass der Vorgang erfolgreich war (Zeilen 13 bis 16).

26 DYNAMISCHES LADEN VON MODULEN 1 # include <dlfcn.h> 2 # include <stdio.h> 3 4 int main(){ 5 6 void* handle; //handle 7 // typdef wegen cast auf richtigen Typ 8 typedef int (*intfunc_t)(); 9 10 // oeffnen der Bibliothek 11 handle = dlopen("./test.so",rtld_lazy); if(null == handle){ 14 fprintf ( stderr, "Fehler bei dlopen: %s\n", dlerror() ); 15 exit(-1); 16 } //Laden des Symbols "test" 19 intfunc_t testfunc = (intfunc_t) dlsym(handle,"test"); if(null == testfunc){ 22 fprintf (stderr, "Fehler bei dlsym: %s\n", dlerror() ); 23 exit(-2); 24 } else { 25 // ausgeben der Adresse der Funktion und Aufruf der Funktion 26 fprintf (stderr,"adresse von testfunc: %x\n",testfunc ); 27 testfunc(); 28 } dlclose(handle); return 0; 33 } Listing 2.3: dynamic linking Beispiel: main.c War dies erfolgreich, so wird das Symbol test aus der Bibliothek geladen (Zeile 19). Auch hier wird wieder überprüft, ob alles geklappt hat(zeilen 21 bis 24). War das Laden erfolgreich, wird seine Adresse ausgegeben und die Funktion ausgeführt (Zeilen 26,27). Die geöffnete Bibliothek wird wieder geschlossen (Zeile 30) und das Programm beendet sich. Nach dem Übersetzen des Programms mittels gcc -o main -ldl main.c kann main ausgeführt werden. Mittels -ldl wird die Bibliothek zum dynamischen Laden von Modulen dazu gelinkt. Wie man sieht, muss die Test- Bibliothek test.so nicht direkt dazugelinked werden. Hier die Ausgabe auf einer Shell:

27 KAPITEL 2. GRUNDLAGEN 13 Adresse von testfunc: b7fe76bc Hallo, dies ist die Testfunktion. Programm 2.1: Testprogramm - dlopen Das Öffnen der Bibliothek und das Laden des Symbols waren also erfolgreich. 2.4 Auswerten der Übergabeparameter Da das System unter Linux entwickelt wird, wird auch zum Auswerten der Übergabeparameter die unter Linux übliche Variante verwendet. Wie bekannt ist, sind die Übergabeparameter in dem Argument argv 4 der main-funktion enthalten. Nun könnte man einen eigenen Parser für diesen String schreiben. Einfacher und komfortabler ist es jedoch, die Funktion getopt (Aus der Headerdatei getopt.h 5 ) zu verwenden. Eine Übersicht über diese Funktion findet man unter [Lib05d]. Die genaue Implementation für diese Arbeit findet sich in Anhang B.6 für den strukturierten Prototypen. Die Implementierung für die entgültige Version findet man in Kapitel Einlesen der Konfigurationsdatei Auch für diesen Aspekt gibt es zwei grundsätzliche Ansätze. Einerseites könnte man auch hier einen eigenen Parser schreiben, um die Konfiguration auszulesen. Andererseits ist dies eine Funktionalität, welche oft benötigt wird. Also ist es vernünftig anzunehmen, dass es eine Bibliothek gibt, welche diese bereitstellt. 4 int main(int argc, char** argv) 5 Bestandteil der GNU C-Library

28 EINLESEN DER KONFIGURATIONSDATEI CCL Eine solche Bibliothek ist die Customizable Configuration Library (siehe [Boo05]). Den Anspruch der CCL zeigt folgendes Zitat von der Homepage der Bibliothek. ccl is the customizable configuration library, a collection of functions for application programmers wishing to interface with usereditable configuration files containing key/value pairs. ccl is customizable because it allows the comment, key/value, and string literal delimiters to be programatically specified at runtime. ccl is designed to be simple and portable; it has a small interface consisting of five functions and is written in ANSI/ISO C. ccl uses avl s implemenation of binary search trees for backend storage. Einleitung auf [Boo05]. Eine Implementierung für den C-Prototypen finden Sie in Kapitel B.7. Allerdings sieht man in dieser Implementierung, dass es mit Hilfe dieser Bibliothek nur möglich ist, einfache Wertepaare auszuwerten. Eine Unterteilung in Sektionen oder eine andere kontextsensitive Anordnung der Wertepaare ist nicht möglich. Ebenfalls ist es nicht möglich, mehrere Konfigurationsdateien in eine Haupt- Konfigurationsdatei einzubinden. Dies wäre zur Konfiguration der Module hilfreich, denn dann gibt es nicht eine grosse Konfigurationsdatei, sondern eine für jedes Modul, welche dann mittels eines Befehls ähnlich dem #include, wie man ihn aus C oder C++ kennt, eingebunden werden kann. Als erster Ansatz ist diese Bibliothek recht erfolgversprechend. Wie man jedoch beim Test im strukturierten Prototyp (Kapitel B.7) festgestellt hat, reicht der Funktionsumfang nicht völlig an die gestellten Anforderungen heran. libdotconf Für diese Anforderungen braucht man eine Bibliothek, welche sehr viele Freiheiten bereitstellt. Die libdotconf bietet die Möglichkeit, eine Apache 6 - ähnliche Konfigurationsdatei für eigene Programme zu verwenden. 6 Ein Webserver -