Aufgaben im Praktikum Verteilte Systeme SS 2004

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 verschiedenen Ansätzen zur Kommunikation in verteilten Systemen zu sammeln. Im zweiten Teil wird ein Peer-to-Peer-basiertes Chatsystem, wie es im vergangenen Praktikum entworfen wurde, weiter entwickelt, gemeinsam die Spezifikation entsprechend ergänzt und schließlich implementiert. Dabei sollen Anforderungen diskutiert, das Protokoll "verfeinert" 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 vorgeschlagene "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 gemeinsame Mailingliste zum Praktikum (siehe Webseite) in der Sie inhaltliche Fragen mit anderen Praktikumsteilnehmern, den Hiwis und den Assistenten diskutieren können. Genieren Sie sich nicht. Wer fragt lernt mehr!

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 alle zwangsläufig im Detail umgesetzt werden, sollten aber zumindest in den Kolloquiumsgesprächen diskutiert werden. Messen Sie ferner für die implementierten Ansätze bei gleichen Mandelbrotmengen-Parametern das kommunizierte Datenvolumen, die Gesamtlaufzeit und den Speicheraufwand.

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ösungen 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: CORBA Variante

Wie Aufgabe 1.2. Jedoch soll zur Kommunikation der entfernte Methodenaufruf einer Service-Klasse per CORBA benutzt werden. Dazu muss zunächst die Dienstschnittstelle mittels CORBA-IDL spezifiziert werden und das System als CORBA Dienst und Client implementiert werden.

Aufgabe 1.4: SOAP Variante

Wie Aufgabe 1.2. Jedoch soll zur Kommunikation der entfernte Methodenaufruf mittels SOAP benutzt werden. Entscheiden Sie selbst, ob Sie zunächst die Schnittstelle mittels WSDL beschreiben wollen und anschließend entsprechende Service- und Client-Programme entwickeln, oder ob Sie erste Ihre Java Service Klasse entwickeln, aus der Sie die WSDL-Beschreibung ableiten. In jedem Fall sollten Sie aus der WSDL-Beschreibung den Client ableiten.

Als SOAP Toolkit steht Ihnen Apache AXIS zur Verfügung (User's Guide). Diverse Tools, die die Entwicklung von SOAP basierten Anwendungen unterstützten (WSDL2Java, Java2WSDL, TcpMonitor) sind bereits integriert. Axis ist als Servlet implementiert und benötigt daher eine Servlet Engine. Für Testzecke (z.B. dieses Praktikum) gibt es den SimpleAxisServer, der diese Funktionalität übernimmt und mittels

java org.apache.axis.transport.http.SimpleAxisServer -p 8080

gestartet wird. Basisverzeichnis für das Deployment ist das Verzeichnis, aus dem der SimpleAxisServer gestartet wurde.

Diskutieren Sie bei der Abnahme mit Ihrem Hiwi alle drei realisierten Ansätze, insbesondere anhand der von Ihnen gemessenen Daten. Wann sind welche Ansätze zu bevorzugen?

Optionen

Die Benutzerfreundlichkeit des Programms kann erhöht werden, indem das Auffinden der verfügbaren Server zur Laufzeit dynamisch passiert und nicht konfiguriert werden muss. Dazu ist eine Multicast Kommunikation geeignet. Für Java Dienste könnte Jini zur Dienstevermittlung benutzt werden. (Davon haben wir aber selbst keine Ahnung. :-)
Sofern UDP verwendet wird, sollte man damit rechnen, dass einzelne Datagramme verloren gehen können. Dadurch darf es nicht zu einer Verklemmung kommen. Timeout-Mechanismen sollten für die Wiederholung von Nachrichten sorgen.
Neben der Möglichkeit, das Gesamtproblem in gleichgroße Teilprobleme zu zerlegen und entsprechend auf die Server zu verteilen, ist es auch möglich, kleinere Teilprobleme zu bilden und diese jeweils an einen unbeschäftigten Server zu delegieren. Sobald ein Server einen Teil bearbeitet hat, bekommt er die nächste Teilaufgabe. Somit ist eine bessere Lastverteilung möglich, die weniger abhängig ist von der Leistung und der Auslastung der einzelnen Server.
CORBA Dienste können in verschiedenen Sprachen implementiert werden. Es ist denkbar, neben einer Java-Implementierung auch einmal eine Implementierung in C oder C++ vorzunehmen und diese Server ebenfalls mit dem in Java implementierten Client zu verwenden.

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

Im zweiten, längeren und auch wesentlich umfangreicheren Teil des Praktikums soll ein Chat-System, das im Praktikum des vergangenen Jahres entworfen wurde, in seiner Spezifikation weiter verbessert und anschließend implementiert werden. Dabei gibt es ein paar Besonderheiten im Vorgehen und in den technischen Anforderungen.

Ein Chat-System erlaubt die Kommunikation 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 Bereich, 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 erfüllen - abgesehen von Ihren unterschiedlichen Implementierungen - alle potentiell dieselben Funktionen. 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). In diesem Fall gehen wir von einer (aus dem PVS 2003) gegebenen Spezifikation aus und wollen diese noch etwas optimieren. Das so spezifizierte Protokoll wird anschließend von allen Gruppen implementiert (Aufgabe 2.2).

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 auf der Mailingliste 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. Dazu dient die "alte" Ausgangsspezifikation der Architektur und des Protokolls (draft-strauss-p2p-chat-03.txt) und die nachfolgend aufgeführten weiteren Anforderungen für Ihre Implementierung. Bitte machen Sie sich diese Trennung zwischen allgemeiner Spezifikation und implementierungsspezifischer Dokumentation deutlich. Ihre Situation ist vergleichbar mit der eines Software-Unternehmens, das eine Chat-Software entwirft und zugleich durch Standardisierungsarbeit Interoperabilität mit anderen Implementierungen anstrebt. Sie sollten sich in dieser Phase auch bereits Gedanken über mögliche Realisierungen und potentielle Probleme machen und diese Überlegungen niederschreiben.

Spezifikation:

Die Spezifikation soll dahingehend erweitert werden, dass nicht mehr alle Chat-Nachrichten im gesamten Netz verteilt (geflutet) werden müssen. Das Routing der Nachrichten soll also "intelligenter" erfolgen.
Die Spezifikation soll dahingehend erweitert werden, dass anonymisierende Kanäle angelegt werden können, in denen die Urheber von Nachrichten für die anderen Teilnehmer unerkannt bleiben.
Achten Sie auf eine korrekte und vollständige Spezifikation, insbesondere im Bereich der Sicherheitsaspekte (verschlüsselte Kanäle, anonymisierende Kanäle).

Entwurf / Implementierung:

Das Programm soll persistent in einer Datei die Adressen potentieller Peers speichern. Diese Datei (neben dem eigenen Zertifikat für die sichere Kommunikation, siehe unten) soll die einzige Information sein, die ein Peer beim Start braucht um am Chat teilzunehmen. Sie soll im Laufe der Zeit durch weitergeleitete Adressen automatisch erweitert werden.
Die Grundfunktionen des Peer-Programmes sollen zunächst das fortlaufende Anzeigen aller empfangenen Nachrichten auf den gewählten Kanälen und das nebenläufige interaktive Eingeben eigener Kommandos und Nachrichten erlauben.
Es soll gemäß der Spezifikation möglich sein, seine Nachrichten zu signieren und zu verschlüsseln. Empfangene signierte Nachrichten sollen verifiziert werden und entsprechend angezeigt werden. Empfangene verschlüsselte Nachrichten sollen entschlüsselt und entsprechend angezeigt werden, sofern man Teilnehmer des verschlüsselten Kanals ist.
Unverschlüsselte und verschlüsselte Kanäle sollen von allen Teilnehmern erzeugt werden können.

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

Werden in der Spezifikation neue Protokoll-Operationen benötigt? Unter welchen Bedingungen werden sie ausgelöst?
Wie soll in Ihrer Implementierung die Nebenläufigkeit des Empfangs und der Eingabe realisiert werden? Threads? select()?
Wie kann ein Kompromiss zwischen ungewünschten Netz-Partitionierungen durch den Abgang oder Ausfall "innerer" Knoten und einer schlechten Skalierung durch voll vermaschte Netze aussehen? Inwiefern soll der Benutzer diese Aspekte der Netztopologie beeinflussen können?

Erstellen Sie im Rahmen der Aufgabe 2.1 ein Dokument, in dem Sie

Ihren Vorschlag für die erforderlichen Erweiterungen der Spezifikation dokumentieren, und
Ihre ersten Gedanken zu Ihrer eigenen Implementierung umreißen (grobes Klassendiagramm, Programmiersprache, voraussichtlich verwendete Bibliotheken/Packages).

Schicken Sie dieses Dokument bis zum angegeben Stichtag als Text-File oder PDF per EMail an pvsadm@ibr.cs.tu-bs.de.

Kolloquium zur Spezifikation

An diesem Termin werden wir gemeinsam mit allen Gruppen ein großes "Entwicklertreffen" abhalten. Darin werden wir der ersten Teile Ihrer Dokumente, also die Vorschläge zur Überarbeitung der Protokoll-Spezifikation, diskutieren und uns (hoffentlich) auf ein überarbeitetes vollständiges und realisierbares Konzept einigen. Die Ergebnisse dieses Kolloquiums werden dann ca. eine Woche später als neue Spezifikation in Form eines neuen Internet-Drafts von den Assis zur Verfügung gestellt. Diese Arbeit entspricht somit etwa der Arbeitsweise von Arbeitsgruppen (Working Groups) der IETF.

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. Die Termine für die Zwischenabgaben sind unbedingt einzuhalten. 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.