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 replizierendes Filesystem entwickelt. Hierbei sollen die Probleme der Synchronisation, Datenkonsistenz und Fehlertoleranz im Vordergrund stehen und zugleich ein Einblick in Dateisysteme und die "betriebssystemnahe" Programmierung in C gewonnen werden.

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" anschauen und versuchen, Ihre Implementierung entsprechend zu ändern oder im Gespräch mit Ihrem Hiwi oder 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 auch die Mailingliste aller Teilnehmer und Betreuer pvs@cip.ibr.cs.tu-bs.de zum Austausch von Informationen oder zum Stellen und Beantworten von Fragen.

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 sollen nicht im Detail umgesetzt werden, können aber diskutiert werden.

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.

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.

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

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

• 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 habe ich 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.

Dieser Teil des Praktikums beinhaltet die Entwicklung eines replizierten, verteilten Dateisystems basierend auf dem NFS-Protokoll. Dazu ist eine einfache Implementierung eines NFS-Servers vorgegeben (pvsnserver), der die NFS Remote Procedure Calls (RPCs) entsprechend beantwortet. Zur Synchronisation der Replikation soll das Majority-Consens-Verfahren benutzt werden.

Im ersten Schritt soll das vorgegebene Skelett eines NFS-Servers erweitert werden. Um nicht direkt mit den NFS-RPCs arbeiten zu müssen, wird die pvsmount-Bibliothek benutzt. Diese leistet bereits alle Vorarbeiten (Anmelden, Übersetzen der RPCs, usw.), so dass nur eine Reihe von C-Funktionen mit der Funktionalität des gewünschten Dateisystems implementiert werden müssen. Der Beispielserver hält Daten nur im Speicher, stellt also eine RAM-Disk dar. Dieser soll so verändert werden, dass die Daten auf Festplatte persistent gesichert werden, und nach einem Neustart des NFS-Servers wieder zur Verfügung stehen.

Das korrekte Arbeiten aller Funktionen (Löschen, Umbenennen, Attribute ändern, etc.) wird getestet. Ein guter umfangreicher Test ist das Kompilieren des eigenen Quelltextes im simulierten Verzeichnis.

Im zweiten Schritt soll ein Konzept ausgearbeitet werden, wie der einfache NFS-Server zu einem replizierenden NFS-Server ausgebaut werden kann. Da nun mehrere Versionen einer Datei auf verschiedenen NFS-Servern existieren können, ist zunächst eine Versionskontrolle zu definieren.

Beim Zugriff auf eine Datei muss jeweils sichergestellt werden, dass mit der aktuellen Version gearbeitet wird. Dazu soll das Majority-Consens-Verfahren eingesetzt werden, bei dem die NFS-Server über Lese- und Schreibzugriffe abstimmen. Sie können davon ausgehen, dass die Anzahl der NFS-Server während eines Laufs konstant ist. Allerdings soll die Anzahl der NFS-Server und die Lese- und Schreibquoren zwischen den Testläufen variiert werden können. Sehen Sie eine einfache Konfigurationsdatei oder Aufrufoptionen für die Parameter vor.

Machen Sie sich an einigen Beispielen den Ablauf des Abstimmungsverfahrens deutlich. Beachten Sie insbesondere, dass eine Kommunikation mit UDP nicht zuverlässig ist. Außerdem ist zu berücksichtigen, dass es mehrere Abstimmungen quasi gleichzeitig geben kann.

Das Konzept wird in Form einer EMail (bitte nur ASCII-Text, PostScript oder PDF) an pvsadm@cip.ibr.cs.tu-bs.de bei den betreuenden Hiwis abgegeben. Nach der Durchsicht werden interessante Aspekte aller Entwürfe in einem gemeinsamen Kolloquium mit allen Praktikumsteilnehmern besprochen. Eventuell sind Nachbesserungen notwendig, falls das Konzept Lücken hat oder inkonsistent ist.

Schließlich soll als dritte Teilaufgabe das Konzept implementiert werden.

Zu den Abnahmekriterien gehören zum einen der Test der Konsistenz aller Dateioperationen (Sehen alle Server wirklich zu einem Zeitpunkt denselben Inhalt des Verzeichnisses?), zum anderen die gleichzeitige Beschäftigung mehrerer Server (z.B. Compilerlauf auf einem Server, ls -ali auf einem anderen). Auch Serverabstürze werden simuliert.

• Directory-Operationen sind zur erfolgreichen Bearbeitung dieser Aufgaben nicht erforderlich. Es wäre dennoch interessant, auch diese zu implementieren. Entsprechende Stubs sind in der pvsmount-Bibliothek ebenfalls bereits enthalten.
• Für das Voting und die Verteilung von Versionsinformationen und Updates sowie für die abschließende Freigabe nach Operationen kann man anstelle mehrfacher Unicast-Nachrichten auch Multicast-Nachrichten verwenden. Achtung: Die Berücksichtigung eines möglichen Verlustes von Nachrichten wird dabei komplizierter.