Fakultät Elektrotechnik und Informatik Studiengang Angewandte Informatik Prof. Dr.-Ing. S. Keller 05.03.2008 Hochschule Ravensburg-Weingarten Systemprogrammierung unter Linux Client Server Projekt Elektronische Tafel SS 08 Seite 1
Inhaltsverzeichnis 1 Projektbeschreibung... 3 2 Funktionalität der Teilprogramme... 5 2.1 Client...5 2.1.1 Die GUI...5 2.1.2 Die Funktionalität...6 2.2 Server...7 2.2.1 Client-Threads...7 2.2.2 Logger...7 3 Interprozesskommunikation... 7 3.1 Server Client...7 3.2 Server Logger...7 3.3 Threads...8 4 Projektdurchführung... 8 5 GUI des Clienten... 9 5.1 Curses - Bibliothek...9 5.1.1 Die Funktionen von CWND...9 5.1.2 Farbe für die Console...10 5.1.3 Schreiben in das Consolenfenster...10 5.1.4 Weitere Informationen...10 5.2 Das Makefile...10 Seite 2
1 Projektbeschreibung In dem Projekt soll eine Client - Server Architektur Elektronische Tafel realisiert werden. Server und Client sind eigenständige Prozesse, die über die Konsole gestartet werden. Der Server darf nur genau einmal gestartet werden. Ein wiederholtes Starten des Servers soll erkannt und zu einer Fehlermeldung führen. Der Client kann beliebig oft gestartet werden. Jeder Client meldet sich beim Server über eine asynchrone Nachrichten-FIFO beim Server an. Für jeden angemeldeten Client wir im Server ein eigener Thread erzeugt, der auf Anfragen des Clients reagiert und dafür sorgt, das der Client immer den aktuellen Inhalt der Tafel erhält. Nach der Anmeldung empfängt der Server Aufträge von den Client-Prozessen, der Client- Thread im Server führt diese Aufträge aus und sendet dem Client in jedem Fall ein Ergebnis zurück Der Server verwaltet alle angemeldeten Clients in einer verketteten Liste Client-Daten. Die Clients besitzen verschiedenen Rollen: Dozent - diesem Client wird beim Starten Schreibrecht zugeteilt. Er kann auf die Tafel schreiben und Tafeleinträge ändern. Student - diesem Client wird beim Starten nur Leserecht zugeteilt. Er kann die Tafel nur sehen Tutor - ein Student, der neben Leserecht auch über Schreibrecht verfügt Jedem Client soll zu jedem Zeitpunkt bekannt sein welche Rolle er einnimmt. Die Rolle eines Client ist im Server in der Datenstruktur Client-Daten gespeichert. Jeder Client sieht immer den aktuellen Tafelinhalt und kann je nach Rolle die Tafel nur lesen, auf die Tafel schreiben oder die Tafel löschen. Ein Client mit Schreibrechten kann neue Textzeilen auf die Tafel schreiben. Die Zeile wird an Ende angefügt. Er kann auch eine vorhandene Zeile editieren. Die Tafel hat eine feste Größe. Ist die Tafel voll, wird keine neue Zeile angefügt. Ein Client mit Schreibrecht kann die Tafel zu jeder Zeit löschen. Wird der Tafelinhalt gelöscht, so soll ein eigenständiger Prozess der Logger - den Tafelinhalt mit Datum und Uhrzeit versehen in eine Textdatei schreiben. Jede gelöschte Tafel wird an die Textdatei angehängt, so dass alle Tafelinhalte gesichert sind. Der Prozess Logger soll als Sohnprozess des Servers realisiert werden und wird vom Server aktiviert, wenn dieser einen Lösche-Befehl von einem Client erhält. Seite 3
Seite 4 Abbildung 1: Aufbau der Anwendung
2 Funktionalität der Komponenten 2.1 Client 2.1.1 Die GUI Jeder Client sieht immer den aktuellen Tafelinhalt und kann je nach Rolle die Tafel nur lesen, auf die Tafel schreiben oder die Tafel löschen. Der Client ist eine reine Konsolenanwendung. Die Konsole wird in mehrere Bereiche eingeteilt. Die unterschiedlichen Bereiche werden durch Farben gekennzeichnet. Die elektronische Tafel wird im oberen Bereich in der Farbe blau dargestellt. Status- und Fehlermeldungen für den Client werden in einer roten Statuszeile angezeigt. Der Eingabebereich des Client beschränkt sich auf eine Konsolenzeile, in der er Kommandos eingeben kann und ist in schwarz dargestellt. Abbildung 2: Aussehen des Client Seite 5
2.1.2 Die Funktionalität Die Darstellung der Tafel und die Eingabe soll nebenläufig durch zwei Threads realisiert werden. Der Eingabe-Thread ist für die Eingabe von Kommandos und Textzeilen zuständig. Die Eingaben werden über asynchrone Nachrichten an den Client-Thread im Server geschickt. Die asynchronenen Nachrichten sind als unix message-queues zu realisieren. Die Darstellung der Tafel übernimmt der Empfangsthread. Den Tafelinhalt erhält dieser Thread ebenfalls über asynchrone Nachrichten vom Server. Auch diese Nachrichten sind als message-queue zu realisieren. Die Kommunikation der beiden Threads erfolgt über globale Daten. Folgende Kommandos sind zu realisieren Kommando Bedeutung Rolle in der das Kommando ausgeführt werden darf /q Client beendet sich Dozent, Student, Tutor /r Schreibrecht anfordern Student /s das ganze System beenden (Shutdown) Dozent /x Tutor gibt Schreibrecht freiwillig ab bzw. Dozent entzieht allentutoren Schreibrecht /e n Zeile bearbeiten (n ist hierbei die Zeilennummer) Die ausgewählte Zeile wird in die Eingabezeile kopiert und kann dort < beliebiger Text ohne / am Anfang> editiert werden Textzeile auf die Tafel schreiben. Wurde vorher keine Zeile ausgewählt wird eine neue Zeile angefügt. Ist die Tafel voll, wird eine Fehlermeldung ausgegeben. /c Tafel löschen Der Tafelinhalt wird in einer Log-Datei archiviert. Dozent, Tutor Dozent, Tutor Dozent, Tutor Dozent, Tutor Für die verschiedenen Rollen der Clients soll immer der gleiche Client verwendet werden ( nicht drei verschiedene Programme ). Seite 6
2.2 Server Der Server verwaltet die elektronische Tafel und regelt den Zugriff der Clients auf die Tafel. Die Tafel ist im Server als shared memory zu realisieren. 2.2.1 Client-Threads Der Server erstellt für jeden Client einen Thread, der die Eingaben aus der Nachrichten- FIFO entgegennimmt und verarbeitet. Dieser Client-Thread hat Zugriff auf die elektronische Tafel. Den aktuellen Tafelinhalt sendet der Client-Thread über Nachrichten an alle angemeldeten Clients. 2.2.2 Logger Der Logger wird durch einen Client-Thread getriggert ( Signale, Pipe,. ). Wenn der Logger aktiviert wird, schreibt er die Tafel mit dem aktuellen Datum und der aktuellen Zeit in eine Textdatei. Danach löscht er die Tafel und reaktiviert den entsprechenden Client- Thread des Servers. 3 Interprozesskommunikation 3.1 Server Client Die Kommunikation zwischen Server und Client soll über asynchrone Nachrichten ablaufen. Die asynchrone Nachrichten sind als Unix Message Queues zu realisieren. Zum anmelden eines Clients an den Server wird eine vom Server eingerichtete main message queue verwendet. Zum Austausch von Kommandos und Rückmeldungen vom Server von/zum Client soll je Cient zwei message queues eingerichtet werden. 3.2 Server Logger Datenaustausch über shared memory. Die Synchronisation zwischen den Prozessen, die Zugriff auf die shared memory haben, soll über binäre Semaphore realisiert werden. Der Logger wird von einem Client-Thread aktiviert. Sie können hierzu Signale oder pipes verwenden. Der jeweilige Client-Thread im Server wartet dann auf eine Quittung des Loggers. Seite 7
3.3 Threads Globale Variablen, auf die mehrere Threads zugreifen sind über binäre Semaphore oder Mutex-Funktionen aus der Thread-Library von LINUX zu schützen. 4 Projektdurchführung Bevor Sie Ihr Projekt realisieren ist ein Entwurf auszuarbeiten. Dieser Entwurf wird vor der Realisierung abgegeben. In ihrem Entwurf sollen die logischen Abläufe der Prozesse, die zeitliche Synchronisation zwischen den Prozessen und die Informationen, die die Prozesse untereinander austauschen, dokumentiert sein. Der Entwurf muss also unter anderem das Synchronisationsprotokoll zwischen Client, Server, deren Threads, und Logger beschreiben. Diese Beschreibung soll grafisch mit einem Petrinetz erfolgen. Zum zeichnen und simulieren des Petrinetzes verwenden Sie den auf der homepage angegebenen Petrinetzsimulator. Zu realisieren sind folgende unabhängigen Prozesse: 1 Server Prozess 1 Logger Prozess ( wird mit dem Server gestartet) 1..n Client Prozesse Innerhalb der Prozesse sind nebenläufige Aktionen durch Threads zu realisieren. Jeder unabhängige Prozess ( ausführbare Datei ) sollte sich aus mehreren Softwaremodulen zusammensetzen. Der Client-Prozess setzt sich z.b. aus den drei Modulen Eingabe, Anzeige, GemeinsameDaten zusammen. Analog ist mit dem Server zu verfahren. Die Semaphoroperationen P, V sollten in einem eigenen Modul realisiert werden. Analog ist mit Senden/Empfangen von Nachrichten zu verfahren. Zu verwendete Software: Texteditor nach Ihrer Wahl Gnu C-Compiler make zur Erzeugung der ausführbaren Dateien Versionsverwaltung mit Subversion Seite 8
5 GUI des Clienten 5.1 Curses - Bibliothek Um den Client in der Console richtig darstellen zu können, wird eine spezielle Bibliothek, die curses Bibliothek, benötigt. Damit ist es möglich, den Cursor frei auf der Console zu versetzen und Text an jeder beliebigen Stelle in jeder Farbe darzustellen. Um die Handhabung dieser Bibliothek etwas zu vereinfachen, werden mehrere Funktionen für das Praktikum zur Verfügung gestellt, die Funktionen der curses Bibliothek zusammenfassen. Diese vereinfachten Funktionen werden im Modul CWND zu Verfügung gestellt. Sie finden die beiden Dateien cwnd.c und cwnd.h auf der Homepage von Prof. Keller. 5.1.1 Die Funktionen von CWND initconsolewindow Mit der Funktion initconsolewindow wird ein Textfenster in der Standartausgabe erzeugt. Die Größe des Fensters ist 80 Zeichen in der Breite und 24 Zeilen nach unten. exitconsolewindow Mit exitconsolewindow wird das Konsolenfenster wieder beendet und die normale Konsole wieder hergestellt. movecursor(int x, int y) Mit der movecursor Funktion wird der Cursor an die Stelle X (Zeichen in der Zeile), Y (Zeile) bewegt. getcursorposition(int *x, int *y) Mit dieser Funktion kann die aktuelle Cursorposition ermittelt werden. printxy(int x, int y char* text) Mit der printxy Funktion wird der Text im chararray an die Position x,y geschrieben. Das char array muss nullterminiert sein. Lesen von Zeichen aus dem Tastaturbuffer Zeichen können mit der getch() Funktion aus dem Tastaturbuffer gelesen werden. getch() liefert einen integer zurück, dieser kann direkt einem char zugewiesen werden. Die Ausgabe auf dem Bildschirm muss von Hand gemacht werden da in der initconsolewindow Funktion das Fenster so eingestellt wurde, dass ein Tastendruck nicht auf dem Bildschirm dargestellt wird. Diese Lösung ist die bessere da sonst der Druck von Sonderzeichen seltsame Zeichen auf dem Bildschirm zur Folge hätte. Seite 9
5.1.2 Farbe für die Console Den Text und Hintergrund farbig zu machen ist nicht schwer. Zunächst müssen Farbpaare definiert werden. Das wird wie folgt realisiert: init_pair(1,color_white,color_black) Die Zahl 1 ist hierbei die Nummer des Paares, die später verwendet wird, um das Farbenpaar zu aktivieren. Der erste Farbparameter ist dann die Farbe der Schrift, die Zewite Farbe ist die Hintergrundfarbe. Benutzt werden die Farben wie folgt: attron(color_pair(1)) Diese Zeile aktiviert das Farbenpaar Nummer 1. Die Farbe ist aktiv, bis sie deaktiviert oder ein anderes farbenpaar aktiviert wird. So wird ein Farbenpaar wieder deaktiviert: attroff(color_pair(1)) 5.1.3 Schreiben in das Consolenfenster Am besten wird die pintxy Funktion aus CWND benutzt, um in das Konsolenfenster zu schreiben. Es kann aber auch direkt eine Funktion aus der curses Bibliothek verwendet werden. Auf keinen Fall darf die printf() Funktion verwendet werden, diese würde die Formatierung des Konsolen Fensters zerstören. Die Curses Bibliothek stellt dazu die printw() Funktion zur Verfügung. Diese funktioniert im Prinzip gleich wie printf(), schreibt den Text allerdings an die aktuelle Cursorposition ohne die Formatierung des Fensters zu zerstören. 5.1.4 Weitere Informationen Weiter informationen sind entweder in den man-pages von Linux zu finden, oder auf dieser Seite: http://www.opengroup.org/onlinepubs/7990989775/xcurses/curses.h.html 5.2 Das makefile Zur Erzeugung einer ausführbaren Datei ist das Linux-Werkzeug make zu verwenden. Die curses Bibliothek wird im Client benötigt und muss im makefile hinzugebunden werden. Das kann durch folgende Zeile erreicht werden: gcc cwnd.c -lcurses -o cwnd Sowohl im Client als auch im Server werden Threads erzeugt. Daher muss die pthread- Bibliothek hinzugebunden werden ( gcc. lpthread ). Seite 10