Aufgaben im Praktikum Verteilte Systeme

Das Praktikum besteht aus zwei Teilen: Ziel des ersten Teils ist es, anhand einer einfachen Anwendung, die nach dem Client/Server-Modell in Java implementiert werden soll, praktische Erfahrungen mit drei verschiedenen Ansätzen zur Kommunikation in verteilten Systemen zu sammeln. Im zweiten Teil wird ein Peer-to-Peer-basiertes Chatsystem entworfen, spezifiziert und implementiert. Dabei sollen Anforderungen diskutiert, ein Protokoll entworfen und Sicherheitsaspekte berücksichtigt werden. Die Programmierung im ersten Teil erfolgt in Java. Im zweiten Teil können Sie die Programmiersprache selbst wählen.

Es sind alle Aufgaben in der angegebenen Reihenfolge und bis zu den angegebenen Terminen zu bearbeiten (d.h. es darf nicht etwa Aufgabe 1.1 ausgelassen oder verschoben werden, weil man der Ansicht sein könnte, man könne sie sich sparen, da Aufgabe 1.2 darauf aufbaut).

Wenn Sie weitere Herausforderungen über das Geforderte hinaus suchen :-), können Sie sich einige "Optionen" zu beiden Teilen anschauen und versuchen, Ihre Implementierung entsprechend zu ändern oder im Gespräch mit Ihrem Hiwi oder den Assistenten diese oder andere Aspekte diskutieren. Legen Sie aber stets zunächst das Hauptaugenmerk auf die grundlegenden Anforderungen. Unwichtig sind im Rahmen dieses Praktikums dagegen Dinge wie z.B. ein besonders hübsches User-Interface mit viel Plüsch.

Die Abnahme der Aufgaben findet in kleinen Kolloquiumsgesprächen mit Ihrem Hiwi im Rechner-Pool statt. Dabei müssen alle Teilnehmer Ihrer Gruppe anwesend sein, da auch alle zum Aufbau und zur Funktion Ihrer Lösungen und zu den verwendeten Mechanismen befragt und letztenendes einzeln bewertet werden. Sollte es einmal ausnahmsweise zu einer Verzögerung bei der Bearbeitung einer Aufgabe kommen, teilen Sie dies Ihrem Hiwi frühzeitig (mindestens 3 Tage vor Ablauf der Aufgabe) mündlich oder per EMail mit.

Wenn Sie grundlegende Probleme bei der Bearbeitung haben, sprechen Sie ebenfalls frühzeitig mit Ihrem Hiwi oder fragen Sie ihn per EMail. Benutzen Sie insbesondere auch die Newsgroup zum Praktikum ibr.lehre.pvs in der Sie inhaltliche Fragen mit anderen Praktikumsteilnehmern, den Hiwis und den Assistenten diskutieren können.

Teil 1: Verteilte Fraktalberechnung

Im ersten Teil des Praktikums sollen Sie ein Programm zur Berechnung von Fraktalen in Java implementieren. Nach einer einführenden Single-Process Variante sollen Sie aus ihrem System verschiedene Formen verteilter Systeme ableiten, indem Sie verschiedene Mechanismen zur Kommunikation einsetzen. Machen Sie sich Gedanken zu den Aspekten Skalierbarkeit, Fehlertoleranz, DoS-Sicherheit. Diese müssen nicht zwangsläufig im Detail umgesetzt werden, können aber zumindest in den Kolloquiumsgesprächen diskutiert werden.

Aufgabe 1.1: Single-Process Variante

Zunächst sollen Sie ein einfaches Java-Programm zur Berechnung und Anzeige von Fraktalen (vorzugsweise nach der Mandelbrotmenge, Dokumentation, Kapitel 5.3.1) erstellen. Das Programm soll die Eingaben der notwendigen Parameter (nmax, Koordinaten von G) erlauben und die errechnete Zugehörigkeit der Punkte in G zur Mandelbrotmenge grafisch anzeigen. Durch Anklicken von zwei Punkten bzw. Aufspannen eines Ausschnittes soll die Neuberchnung für ein Teilgebiet möglich sein.

Es ist ratsam, beim Entwurf dieses Programms bereits an die folgenden Aufgaben zu denken und die Berechnung für ein gegebenes Gebiet in eine separate Klasse zu kapseln.

Aufgabe 1.2: Sockets Variante

Ausgehend von Ihrem Programm aus Aufgabe 1.1 soll nun die Berechnung der Punkte in ein separates Server-Programm ausgelagert werden. Dieser Compute-Server soll mehrfach im LAN gestartet werden. Das aus Aufgabe 1.1 entwickelte Client-Programm soll in der Lage sein, meherere dieser Compute-Server zur Berechnung von Teilgebieten zu benutzen und diese Teillösung zur Gesamtlösung zusammenzusetzen.

Zur Kommunikation zwischen Client und Servern sollen TCP-Sockets oder UDP-Sockets (ggf. mit Multicast) benutzt werden. Wie die Daten eines Berechnungs-Requests und einer Response in Nachrichten oder Datagrammen kodiert werden, sollen Sie selbst entscheiden.

Aufgabe 1.3: Java RMI Variante

Wie Aufgabe 1.2. Jedoch soll zur Kommunikation der entfernte Methodenaufruf einer Service-Klasse per RMI benutzt werden.

Aufgabe 1.4: CORBA Variante

Wie Aufgabe 1.2. Jedoch soll die Dienstschnittstelle mittels CORBA-IDL spezifiziert werden und das System als CORBA Dienst und Client implementiert werden.

Optionen

Teil 2: Ein Peer-To-Peer Chat-System

Im zweiten, längeren und auch wesentlich umfangreicheren Teil des Praktikums soll ein Chat-System entworfen und implementiert werden. Dabei gibt es ein paar Besonderheiten im Vorgehen und in den technischen Anforderungen.

Ein Chat-System erlaubt die Kommunkiation innerhalb einer Gruppe von Personen durch den synchronen fortlaufenden Austausch von Text-Nachrichten, die von jeder Person geschrieben und an alle Teilnehmer einer Gruppe verteilt werden. Personen werden durch (hier EMail-)Adressen und Gruppen durch sog. Kanäle identifiert. Typische Chat-Programme präsentieren sich grafisch oder textbasiert meist mit einem großen Bildbereich, in dem die empfangenen (und selbst gesendeten) Nachrichten fortlaufend angezeigt werden, und einem kleinen Bereich, in dem eigene Nachrichten eingegeben werden.

Was das in diesem Praktikum zu entwickelnde Chat-System technisch von den meisten anderen Systemen unterscheidet, ist die Tatsache, dass es nicht auf einem zentralen Server (oder mehreren) beruht. Stattdessen sind alle "Knoten" im Netz der Chat-Teilnehmer gleichwertig. Sie führen - abgesehen von Ihren unterschiedlichen Implementierungen - alle potentiell denselben Code aus. Es handelt sich also um eine Peer-To-Peer-Architektur und nicht um eine Client/Server-Architektur.

Die Programme, die von jeder einzelnen Praktikumsgruppe entwickelt werden, sollen am Ende des Semesters auch untereinander kommunizieren können. Es genügt also nicht, seine eigenen Überlegungen umzusetzen und mehrere Instanzen desselben Programms mittels eines eigenen Protokolls kommunizieren zu lassen. Stattdessen muss eine Phase der gemeinsamen Protokollspezifikation vorweggehen (Aufgabe 2.1). Dieses Protokoll wird dann von allen Gruppen implementiert (Aufgabe 2.2). Grundlegende Protokolloperationen sind zwingend erforderlich, andere sind optional.

Die Programmiersprache, in der Sie Ihr Chat-Programm implementieren, können Sie frei wählen. Sollten Sie sich hier für Java oder C entscheiden, können Sie damit rechnen, dass Ihre Hiwis und Assis Sie bei eventuell auftretenden Fragen oder Schwierigkeiten gut unterstützen können. Sollten Sie sich für eine "exotische(re)" Realisierung entscheiden (Perl, Python, Assembler, Ada, Caml, Emacs Lisp, ...), so ist das ebenfalls sehr willkommen, Sie sollten aber damit rechnen, bei Problemen ggf. auf ihren eigenen sportlichen Umgang mit Dokumentationen oder sonstigen Ressourcen angewiesen zu sein. Außerdem sollten Sie dann rechtzeitig prüfen, ob ggf. notwendige Software-Bibliotheken, etwa für die Socket-Kommunikation und die Verschlüsselung und Signierung von Nachrichten, verfügbar und hinreichend funktional sind.

Fragen jeder Art und in jeder Phase der Bearbeitung, z.B. Fragen zum Verständnis, Diskussion angedachter Lösungen, Suche nach Java-Klassen, C-Funktionen oder Bibliotheken mit bestimmter Funktionalität, organisatorische Fragen, etc., werden in der Newsgroup ibr.lehre.pvs besprochen. Dies dient dem fairen Austausch von Informationen unter allen Teilnehmern und Betreuern.

Aufgabe 2.1: Anforderungen, Entwurf, Spezifikation

Im ersten Schritt geht es darum, die Anforderungen genau zu verstehen und zu konkretisieren. Es sind einige Vorstellungen von der erwarteten Funktionalität gegeben. Die Situation ist für Sie vergleichbar mit der eines Software-Unternehmens, das mit einem neuen Kunden (Ihre Hiwis und Assis) den Anforderungskatalog verhandelt. Sie sollten sich in dieser Phase auch bereits Gedanken über mögliche elegante Realisierungen und potentielle Probleme machen und diese Überlegungen niederschreiben.

Es gibt eine Menge von Fragen, die Sie in dieser ersten Aufgabe zu klären haben. Hier nur ein kleine Auswahl...

Erstellen Sie im Rahmen der Aufgabe 2.1 einen groben Entwurf in Form eines ca. 5-8 seitigen Dokumentes (Seiten schinden güldet nicht!), in dem Sie einen groben aber vollständigen technischen Einblick in ihre angestrebte Architektur vermitteln. Darin sollten unter anderem die o.g. Fragen diskutiert und die gestellten Anforderungen erfüllt werden. Von zentraler Wichtigkeit ist eine Beschreibung aller notwendigen Protokoll-Operationen. Dieses Dokument ist bis zum angegebenen Stichtag als EMail (plain text, PostScript oder PDF; kein Word, Framemaker, o.ä.) an pvsadm@ibr.cs.tu-bs.de zu schicken.

Kolloquium zur Spezifikation

Etwa eine Woche nach Abgabe Ihres Entwurfs (siehe Terminübersicht) werden wir gemeinsam mit allen Gruppen ein großes "Entwicklertreffen" abhalten. Darin werden wir Ihre Entwurfsüberlegungen diskutieren und uns (hoffentlich) auf ein möglichst vollständiges und realisierbares Konzept einigen. Die Ergebnisse dieses Kolloquiums werden dann ca. eine Woche später als Protokoll-Spezifikation (etwa in Form eines Internet-Drafts) von den Assis zur Verfügung gestellt.

Als mögliche Termine bieten sich die beiden Übungstermine (4. und 5. Juni, jeweils 13.3o Uhr) an. Bitte halten Sie sich zunächst diese beiden Termine frei und teilen sie uns (pvsadm@ibr.cs.tu-bs.de) mit, falls es Ihnen unmöglich ist, an einem dieser Termine teilzunehmen. Wir werden den endgültigen Termin, an dem es weniger Konflikte gibt, am 30. Mai in der Newsgroup und auf der Webseite bekanntgeben.

Aufgabe 2.2: Implementierung, Tests

Nun gilt es, die gemeinsam entworfene Spezifikation des Protokolls in eine individuelle Implementierung zu verwandeln. Wir empfehlen Ihnen, in einem Top-Down-Verfahren zunächst einen groben Entwurf ihrer Module bzw. Klassen vorzunehmen, deren Schnittstellen zu klären und dann in einer für Ihre Team-Arbeit angemessenen Weise die aufgaben-verteilte Detaillierung und Implementierung voranzutreiben. An zwei festen Terminen im Verlauf der Implementierungsphase (siehe Terminübersicht) stellen Sie Ihre bis dahin geleistete Arbeit Ihrem Hiwi vor. Dies dient der Sicherstellung, dass Sie auf dem richtigen Weg sind und bleiben. Außerdem werden sich sicherlich Möglichkeiten entwickeln, gemeinsam mit anderen Gruppen bereits im Laufe der Implementierungsphase die Interaktion der verschiedenen Realisierungen zu testen, so dass die Kolloquien zur endgültigen Abgabe in der letzten Semesterwoche dann möglichst wenige Überraschungen bringen.