Verteilte Systeme

Verteilte Systeme gliedern sich in Teilsysteme (Knoten), die auf verschiedene Rechnerplattformen verteilt sind. Die Knoten können miteinander kommunizieren. Gemeinsam gewährleisten sie das Funktionieren des Gesamtsystem.

Wir realisieren von Grund auf eine verteilte Applikation. Nachdem wir Remote Method Invocation (RMI) als sehr mächtigen Kommunikationsmechanismus kennen gelernt haben, verwenden wir hauptsächlich diesen, ergänzend aber auch Web Services. 

Verteilte Spiele bieten sich als Studienobjekte an, weil an ihnen interessante Mechanismen studiert werden können und weil sie gegenüber irgendwelchen trockenen Beispielen auch mehr Spass machen.

In den letzten Kursdurchführungen haben wir uns auf Kartenspiele konzentriert. Der Grundaufbau der meisten Kartenspiele kann gleich gewählt werden. Konkrete Spiele, wie in unserem Beispiel "Jass", benötigen dann noch ein paar spezifische Ergänzungen.

Bei unserem Jass muss sich jeder Spieler zuerst mit Namen und Photo auf unserem zentralen LDAP-Server registieren.

Irgend ein Spieler kann eine Spielrunde starten. Das Spiel wird dann im LDAP-Server eingetragen und damit für alle anderen potentiellen Mitspieler sichtbar. Wer Lust hat, eine Runde zu jassen, startet auf seiner Maschine das GUI (siehe Bild), schliesst sich einer Spielrunde an und kann dann mitspielen. Als verteiltes Spiel funktioniert es selbstverständlich weltweit.

Verteilte Algorithmen

Verteilte Systeme weisen spezielle Eigenheiten auf, die sich in entsprechenden Algorithmen niederschlagen.

Beispielsweise werden Daten oft nicht an einer Stelle zentral, sondern über die Knoten verteilt verwaltet. Um die Sicherheit gegen Datenverlust und die Verfügbarkeit zu erhöhen, werden sie oft sogar redundant gespeichert. Es gibt also für jedes Datum mehrere Kopien. Sofern nicht gerade alle Knoten, die Kopien speichern, ausfallen und somit wenigstens noch eine Kopie übrig bleibt, sind die Daten für den noch funktionierenden Rest des Gesamtsystems immer noch verfügbar. Schalten sich temporär ausgefallene Knoten nach einer gewissen Zeit wieder zu, sind in der Zwischenzeit veraltete Kopien nachzuführen. Dies muss im Betrieb geschehen, also in einer Situation, in der ständig Daten gelesen und auch neu geschrieben werden. Natürlich sind besondere Algorithmen vorzusehen, damit den Benützern gegenüber eine sogenannt konsistente Sicht geboten werden kann. Darunter versteht man beispielsweise, dass einem Benutzer nicht vom einen Datum ein aktueller und von einem anderen ein veralteter Wert ausgeliefert werden darf.

Das Beispiel der Datenverwaltung soll zeigen, dass verteilte Systeme redundant ausgelegt werden können, so dass in einem gewissen Mass Konten ausfallen können, ohne die Funktion des funktionierenden Rests total zu beeinträchtigen.

Ein weiteres Charakteristikum sind parallele Abläufe. Jeder Benutzer startet eine Aktivität, die sich als Prozess über die Knoten hinweg zieht. Verteilte Algorithmen müssen diese Prozesse koordinieren.

Diese, natürlich sehr unvollständige Aufzählung spezifischer Eigenschaften verteilter Systeme soll zeigen, dass zu deren Beherrschung ein fundierter theoretischer Background nötig ist.

Aus der Fülle der verteilten Algorithmen greifen wir zuerst das Thema logische Zeit und logische Uhren heraus. Logische Uhren können Zeiten (Zeitstempel) liefern, die mit den realen Zeitangaben wenig zu tun haben, aber trotzdem gewisse, für viele Algorithmen ausreichende Bedingungen erfüllen. Beispielsweise muss es so sein, dass ein Ereignis a, welches vor dem Ereignis b stattfindet, einen kleineren Zeitstempel ts(a) kriegen muss, wie derjenige ts(b) des Ereignisses b.

Mit Hilfe logischer Uhren können wir dann die Synchronisation verteilter Transaktionen nach den Timestamp-Ordering Verfahren betrachten. Verteilte Transaktionen sind Operationsfolgen, die gewisse Eigenschaften aufweisen. Beispielsweise wird verlangt, dass entweder alle oder dann halt gar keine Operation ausgeführt wird. "Halbe" Transaktionen sind nicht erlaubt, da sie zu inkonsistenten Zuständen führen können.