Beruflich Dokumente
Kultur Dokumente
C UEBUNG
Arbeiten Sie in max. 2er Gruppen auf der lokalen Linux Installation in den EDV Sälen
oder auf Ihrem Laptop.
1. FHRemoteMemo Teil 1
Erstellen Sie eine Client-Server Anwendung in C unter Linux zum Übertragen von
Kurztextnachrichten mithilfe von Socket Kommunikation.
Szenario: Der Client schickt eine Textnachricht mit einer max. Länge von 140 Zeichen.
Der Server speichert die Nachricht in einem Protokollfile.
• Der Client wird mit einer IP Adresse und einem Port als Parameter gestartet
• Der Server wird mit einem Port und einem Verzeichnispfad
(Speicherverzeichnis) als Parameter gestartet.
• Der Server soll in der ersten Ausbaustufe als iterativer Server ausgelegt
werden (keine gleichzeitigen Requests)
• Der Client connected mittels Stream Sockets über die angegebene IP-Adresse
/ Port Kombination zum Server und schickt Requests an den Server.
• Der Server erkennt und reagiert auf folgende Requests des Clients:
o MSG: Sendet eine Nachricht vom Client zum Server, der die
übertragene Nachricht an die Protokolldatei anhängt.
Beispiel: > MSG Ich bin eine Testnachricht.
Der Server reagiert mit einer Antwort: „Nachricht erhalten“ und gibt die
Nachricht wieder
Beispiel: > Nachricht erhalten: „Ich bin eine
Testnachricht.“
o RECV DATE: Der Server schickt an den Client seine aktuelle Systemzeit
und Datum
o RECV STAT: Der Server liefert dem Client folgende Informationen:
Anzahl der in dieser Sitzung gesendeten Nachrichten, Anzahl der
Einträge in der Protokolldatei
o MEMO: Client zeigt den Inhalt der Protokolldatei an, die auf dem Server
gespeichert ist.
o QUIT: Logout des Clients
• Für den Client ist kein GUI notwendig, es reicht wenn die Protokollbefehle
eingeben werden können und die Rückmeldungen des Servers angezeigt
werden.
Hinweise
Es wird nur eine Protokolldatei angelegt und gespeichert.
Neue Nachrichten werden ans Ende der Datei angehängt. Überlegen Sie sich einen
sinnvollen Dateinamen und mögliche Unterscheidungskriterien für die Einträge (z.B.
vorangestelltes Datum mit Uhrzeit o.ä.) Alle Antworten des Servers werden ebenfalls
in dieser Datei gespeichert.
Überlegen Sie sich ein sinnvolles Protokoll zum Datenaustausch zwischen Client und
Server.
Übersicht über alle Low-Level I/O Funktionen, wie z.B. open,close,read,write,fcntl
z.B. unter http://www.pronix.de/pronix-55.html
Verwenden Sie zum Lesen aus dem Socket bis zum nächsten Newline z.B. die
Funktion readline() aus dem Tutorial tcpip_linux-prog-details.pdf
2. FHRemoteMemo Teil 2
Erweitern Sie ihre Client-Server Anwendung zum Übertragen von Nachrichten wie
folgt:
• Der Server soll nun als nebenläufiger Server ausgelegt werden (parallele
Requests von mehreren Clients). Sie können entweder fork() oder Threads
verwenden.
• Das Protokoll wird um einen LOGIN Befehl erweitert. Der Client schickt LOGIN
<username> <password> an den Server. Der Server verbindet sich mit dem FH
LDAP Server und versucht den User zu authentifizieren. Bei ungültiger
Anmeldung verweigert der Server die MSG, MEMO und RECV Befehle und
wartet auf einen erneuten LOGIN Request. Hinweis: Das Passwort sollte nicht
im Klartext angezeigt werden.
• Aus Sicherheitsgründen beendet der Server jedoch die Socket Verbindung zum
Client nach 3 fehlerhaften LOGIN Versuchen und sperrt die IP-Adresse des
Clients für eine gewisse Zeitspanne (Konstante mit #define definieren, z.B. 30
Minuten). Verwalten Sie daher am Server eine geeignete Datenstruktur für die
gesperrten Clients.
• Es soll unterschieden werden können, welche Nachricht von welchem Client
gesendet wurde.
Hinweise
Verwenden Sie für die LDAP Anbindung die OpenLDAP C API (Include Datei
<ldap.h>, gcc Option –lldap)
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-SoftwareDevelopment.html
Achten Sie auf korrekte Fehlerabfragen und beachten Sie die Richtlinien der C-
Programmierung unter Linux. Es dürfen keine Zombie-Prozesse erzeugt werden!
Optionale Zusatzaufgaben
Der Msg Befehl kann optional auch dahingehend erweitert werden, dass der
Server die Nachricht an alle verbundenen Clients broadcastet. Eine mögliche
Implementierung wären Multicasts über UDP.
3. Abgabe
Allgemeine Hinweise:
• Der Quellcode sollte dokumentiert sein
• Geben Sie, wo nötig, sinnvolle Fehlermeldungen aus und fangen Sie
Falscheingaben korrekt ab.