Alcatraz

Architektur des Gesamtsystems

Server Struktur

Ein Server fungiert als Koordinator, der nach dem Bully Algorithmus gewählt wird.

Registrierungs-Anfragen können an jeden der Server ergehen, allerdings müssen diese an den Koordinator weitergeleitet werden. Nur der Koordinator entscheidet ob eine Registrierung erfolgreich ist, und propagiert in diesem Fall die erfolgte Registrierung an alle Server. Dies entspricht einem Primary Based Backup Protokoll.

RMI Registry

• Jeder Server hat eine lokale Registry.
• Jeder Server initialisiert ein RegistryServer Object und registriert es bei seiner lokalen Registry. In weiterer Folge wird dieses RegistryServer Objekt nur auf Anweisung des als Koordinator fungierenden Servers aktualisiert.
• Jeder Server fungiert als Registry-Proxy für die Clients (siehe RMI Proxy)

RMI Proxy

Jeder Server fungiert als RMI Proxy für einen Client. Jeder bind-Request, der an einen der Registry-Proxies ergeht, wird an den Koordinator weitergeleitet, der eine eindeutige URL vergibt, und weiters diesen Request auf alle Server repliziert.

Die bind-Methode wird vom RegistryServer Objekt bereitgestellt.

Kontaktieren des Registry Servers

Clients haben eine Liste mit RMI-URLS via Konfigurations-Datei hinterlegt. Sobald ein Client gestartet wird, versucht er mit Naming.lookup() der Reihe nach über eine der URLS ein RegistryServer Object zu erhalten.

Spezifikation des Ablaufs zwischen Client und Registrierungsserver zum Starten des Spiels

2 Phasen: Registrierungsphase und Initialisierungs-Phase.

Voraussetzung für diese Phasen ist, dass die Registrierungsserver online sind, und das RegistryServer Object in der RMI Registry registriert haben.

Registrierungsphase

Clients versuchen sich, nachdem sie ein RegistryServer Object erhalten haben, sich über dieses zu registrieren. Dazu muss lokal vom Client ein Register Object erstellt werden, und diese in der RMI Registry (via Proxy) registriert werden.

• vom Client wird eine Register-Request Methode aufgerufen, die als Parameter die rmi-URL des Register Objekts enthält.
• dieser Request wird an den Koordinator weitergeleitet
• der Koordinator prüft den Request nach folgenden Voraussetzungen:
  • ist der Name des Spielers noch frei ist
  • die Maximal-Anzahl der Spieler bereits erreicht
  • ist die Registrierungsphase bereits abgeschlossen
• der Koordinator ruft die reject oder accept Methode des Registry Objects auf, und propagiert diese Entscheidung an die anderen Server

Die Registrierungsphase läuft ab wenn:

• eine bestimmte Zeit vergangen ist
• die maximale Spieranzahl erreicht ist

Sobald die Registrierungsphase abgelaufen ist, beginnt die Initialisierungs-Phase. Der Beginn diese Phase wird den Clients vom Koordinator (über einen Aufruf am Request Object) mitgeteilt, und an die anderen Server propagiert.

Initialisierungs-Phase

• Clients initialisieren ein at.falb.games.alcatraz.api Object
• Clients initialisieren ein Alcatraz-RMI-Wrapper Objekt, und registrieren dieses über den RMI-Proxy.
• Clients übergeben diese URL an das RegistryServer Objekt.
• Clients erhalten URL's der Alcatraz-RMI-Wrapper Objekte ihrer Mitspieler über eine Methode des Register Objekts, die vom Server aufgerufen wird, sobald alle URL's aller Mitspieler registriert sind.
• Mit dem übertragen dieser URL's endet die Aufgabe des Servers, und das Spiel beginnt.

Spezifikation des Ablaufs zwischen Client und Client zum Austausch der Züge

Über ein RMI fähiges Wrapper Objekt für die at.falb.games.alcatraz.api.Alcatraz Klasse werden die Züge der Spieler ausgetauscht.

Spezifikation der Mechanismen um Serverausfälle tolerieren zu können

• RMI Registry ist redundant
• RegistryServer Object ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary Backup Protokoll redundant gehalten.

TODO: abklären ob rmiregistry eventuell geclone't werden kann - dann könnten ausgefallene server einen restore machen. falls das nicht geht ist ein ausgefallener server für immer weg !!