Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Projekt Alcatraz Java RMI / Spread - Gruppe A4.

Ähnliche Präsentationen


Präsentation zum Thema: "Projekt Alcatraz Java RMI / Spread - Gruppe A4."—  Präsentation transkript:

1 Projekt Alcatraz Java RMI / Spread - Gruppe A4

2 Agenda Architektur des Gesamtsystems Ablauf zwischen Server und Client
Ablauf Client 2 Client Serverausfälle tolerieren Remote Interface Definition Server Remote Interface Definition Client © 2009 FH Technikum Wien

3 Architektur © 2009 FH Technikum Wien Spread Deamon
Läuft auf jeden Server RMI Registry Nur der lokale Server registriert sich bei der RMI Registry, damit man sie wieder finden kann Spread Group: Es gibt in unseren System eine einzige SPREAD Gruppe= „Alcatraz“ Server: Ist jeweils ein Prozess(es ist bei uns so definiert, dass jeder Server auf einer eigenen Maschine läuft) Muss sich beim hochstarten bei seiner RMI Registry anmelden Es gibt zu jeden Zeitpunkt höchstens einen MasterServer(welcher verantwortlich für die Registrierung der Clients und die Weiterleitung der Informationen der Clients an die anderen Server ist =Active Replication) Alle Reserve Server fragen in Zyklischen Zeitabständen(500ms oder 1s) den MasterServer ab, ob der MasterServer noch aktiv ist, wenn nicht Election(neuer MasterServer) Election des neuen Master Server: Einfach der Reserve Server dem es aufgefallen ist, dass der Master Server weg ist Tritt ein neuer Reserve-Server Prozess der Gruppe hinzu-> so wird eine Spread Nachricht ausgesendet und jeder Server updatet für sich selbst die Liste der Server ab. Gleichzeitig holt sich der neue Reserve-Server Prozess vom MasterServer die Client Liste. Versucht ein Client sich bei einem Reserve Server zu verbindenÜberprüft der Reserve Server ob es einen MasterServer gibt, wenn ja: wirft er eine ImNotTheMasterException und gibt innerhalb der Exception auch noch den Namen des MasterServers zurück, damit sich der Client die Proxy Referenz des MasterServers holen kann und sich bei ihm Registrieren. Wenn Nein:Ruft er die Elecation aus und nimmt den Aufruf des Clients sofort entgegen. Client: Versucht über dem ihm bekannten Server die RMI Registry anzusprechen und das Proxy Objekt für den ihm Bekannten Server zu holen Der Client kennt zumindest den Namen des Servers um ihn via NamingService zu erreichen Um einen Spiel betreten zu können muss sich der Cient bei dem MasterServer melden(Register dem Client ist es möglich den UserNamen selbst einzutragen) Ist zum RegisterZeitpunkt der eine Server bzw. kein Server aktiv Pech gehabt, wir können nicht alles abfangen © 2009 FH Technikum Wien

4 Ablauf Server RMI Registry and SPREAD Deamon running Start Server
FALSE ANZ<4 ANZ == Maximum Is Master Server TRUE WAIT REGISTER BIND  SPREAD FORCE START FALSE TRUE FALSE BIND: Hierbei wird die GroupCommunication erledigt, dass heißt zur Gruppe hinzu treten, lient liste holen(sofern vorhanden) Manual Start: Jeder Client hat die Möglichkeit ein Spiel sofort zu starten(dieses wird dann sofort gestartet sobal 2 Spieler im Spiel sind) Bei Register wird der Client nur der Liste hinzugefügt Wenn es gleich der Maximum Anzahl ist wird sofort gestartet Bei StartGame wird via einen RemoteCallback auf die Clients zugegriffen und bei jedem einzelnen Client wird das Spiel gestartet ANZ >1 Backup Server START GAME TRUE I‘M BACKUP I HAVE TO WAIT © 2009 FH Technikum Wien

5 Registrierungs Form Client
Das wäre jenes Form welches beim Start des Clients geladen wird. In der Server Combobox sind alle Server geladen welche in einer XML-Config Datei eingetragen, zusätzlich soll es möglich sein eine händische Texteingabe zu ermöglichen. Player Name: Einfache Texteingabe State: Soll anzeigen: „Waiting“,“Connecting“. Unter dem State gibt es eine ProgressBar(mal schauen ob wir die brauchen). Button Register: Registriert sich beim Masterserver und wartet bis es 4 Spieler für ein Spiel gibt. Button Start Now: Erzwingt einen sofortigen Spielstart, sofern bereits mindestens 2 Spieler diesem Spiel begetreten sind. © 2009 FH Technikum Wien

6 Ablauf Client USER ENTERS DATA START CONNECT REGISTER LOOKUP REGISTER
ANZ == MAX START GAME ON CLIENTS FINISH END PLAY WAIT START BUTTON ANZ== 1 Lookup: Versuchen mit dem eingetragenen Server zu verbinden Register: Beim Server zu registrieren StartButton: Der User kann ja immer das Spiel sofort starten ANZ> 1 START GAME ON CLIENTS MANUAL START © 2009 FH Technikum Wien

7 Zeitlicher Ablauf UNDEFINED TIMESPAN EVERY CLIENT LOOKUP SERVER
START THE GAME RMI - REGISTRY REGISTER BIND SERVER © 2009 FH Technikum Wien

8 Client 2 Client RMI: Player, Prisoner, Row und Column were sent
Client X Client Y Zug 1 WAIT RMI: Player, Prisoner, Row und Column were sent Do Remote Move Do Local Move RMI: NextOne() WAIT Zug 2 RMI: Player, Prisoner, Row und Column were sent Do Local Move Do RemoteMove Es wird beim Holen der daten vom Server angenommen, und einen Lookup auf den MasterServer gemacht haben. Der Server sendet beim Starten des Spiels zusätzlich noch die ID des jenigen Spielers mit welcher den ersten Zug machen darf. Nach dem der Client mittels GUI den ersten Zug getätigt hat, werden wir via MoveListener benachrichtigt und müssen diese Änderung den anderen Clients mitteilen. Fährt abwechselnd fort bis: Sieg bzw. Niederlage oder Abbruch des Spieles RMI: NextOne() Zug 3 WAIT © 2009 FH Technikum Wien

9 Client 2 Client Fehlerfall: Spielpartner antwortet nicht  Timeout
Spielabbruch Der zu ziehende Spieler zieht nicht Human Error – Der Client ist manuell zu beenden Spielzug Übertragung im Transaction Modus Der nächste in der Reihe bekommt seinen Zug erst, wenn bei alle anderen Clients der Zug erfolgreich zugestellt wurde. © 2009 FH Technikum Wien

10 Serverausfälle W Spread Join spread group as slave
Client want to register Master Already Exists Client has Looked Up No Start Server Master Server Bind to rmi-Registry Yes Initial Backup Request Client-Objects from Master New Clients would be announced to each Backup Normal Backup Server Über SPREAD bekommt man mit, wenn jemand die Gruppe verlässt oder dazukommt: Dort hängen wir uns rein und jeder Server updated für sich selbst seine ServerListe. Bei Spread kann hat man zugriff auf die Liste von Gruppenmitgliedern. Wenn eine neuer Server gestartet wird gibt es zwei Möglichkeiten: Er ist der erste Er ist NICHT der erste In beiden Fällen wird er nicht zum Master durch unseren Mechanismus, dass bei einem RegisterClient bzw. Polling der Backup Server nach den Master wird automatisch eine Election ausgerufen. Spread © 2009 FH Technikum Wien

11 Serverausfälle Failure des Backup Servers  Kein Problem. Restart durch Admin Failure des Master Servers: Failure of Master Detected by Backup Backup becomes Master Master Sends Update to Group Election of new Master Verwendung von Active Replication über Spread Election Mode = Der erste der es erkennt Verwendung von Verteilten Transaktion erst wenn jeder die Änderung erhalten hat, gilt sie Failure of Master Detected by Backup: Client versucht ein Register bei einem Backup Server, somit Überprüft der Slave ob der Master noch lebt wenn nicht dann hat er Detected Election of New Master = Der Backup Server welcher den Failure des Masters erkannt hat Backup Server bekommt Master wenn er es jeden in seiner Gruppe berichtet hat und wird danach zum Master © 2009 FH Technikum Wien

12 Interface IBackupServer
public interface IBackupServer extends Remote { public Boolean IsAlive() throws RemoteException; public Boolean IsMaster() throws RemoteException; public void syncGroup(Object[] data) throws Exception; } IBackServer dient als Interface für die Server-Seite, d.h.: mit diesem Interface sprechen die Server sich untereinander an IsAlive- prüfen ob der Server noch aktiv ist IsMaster – prüfen ob es sich bei dem Server um einen Master handelt syncGroupDie Server müssen über die Liste der Clients aktuell gehalten werden © 2009 FH Technikum Wien

13 Interface IGameServer
public interface IGameServer extends Remote { public boolean startGameNow() throws RemoteException; public void registerClient(IClient client) throws RemoteException, IImNotMasterServerException; } IGameServer dieses Interface dient der Client – Server kommunikation, d.h.: der Client spricht die Server über dieses Interface an. Damit erreichen wir die Trennung von Client-Game Registrierung und Server-Verwaltung. startGameNow Wird für unseren erzwungen Spielstart benötigt(damit auch nur 2 Spieler spielen können) Auf den Clients den Anmeldeschirm verschwinden lassen und die Spiele GUI erscheinen lassen registerClient- IImNotMasterServerException(Damit teilen wir dem Client mit, dass dies nicht der MasterServer ist, gleichzeitig geben wir im in der Exception den entsprechenden Stub des MasterServers mit. © 2009 FH Technikum Wien

14 Klasse GameServer Attribute:
Liste der aktive Server(inklusive MasterServer) Referenz auf MasterServer Liste von Games Game wird die einzelnen Clients enthalten Implementiert AdvancedMessageListener Interface dadurch bekommt man Änderungen in der Server Gruppe mit © 2009 FH Technikum Wien

15 Interface IGameClient 1/2
public Boolean IsAlive() throws RemoteException; public void doRemoteMove(Player player, Prisoner prisoner, int rowOrCol, int row, int col) throws RemoteException; public void nextOne() throws RemoteException; public void doStartGame(List<IClient> others,String firstPlayerId) throws RemoteException; IsAlive – Um zu überprüfen ob der Client noch aktiv ist doRemoteMove – Um einen entfernten Client zu sagen, dass er folgenden Zug machen soll nextOne– Um einen Client davon in Kenntnis zu setzen, dass er jetzt dran ist. doStartGame – Das ist der Fall wenn die SpielerAnzahl == Max(4) ist, also KEIN erzwungener Spielstart. Um das Spiel zu starten, wird vom Server aus auf jeden Client aufgerufen, der Client welcher die Übergebene PlayerID hat darf beginnen mit dem 1. Zug. © 2009 FH Technikum Wien

16 Interface IGameClient 2/2
public String getPlayerName() throws RemoteException; public void setPlayerId(String playerId) throws RemoteException; public String getPlayerId() throws RemoteException; getPlayerName, setPlayerId,getPlayerID wird wahrscheinlich benötigt. © 2009 FH Technikum Wien

17 Klasse GameClient Attribute
IsCurrentActivePlayer Liste von Clients(Mitspieler) Liste von Servern(kann auch nur einer sein) Spielername SpielerID – wird vom Server vergeben Leitet von UnicastRemoteObject abdadurch ist der Proxy serialisierbar und somit als Parameter über RMI versendbar System.setSecurityManager(new RMISecurityManager()); Server Namen bzw Adressen werden in einem XML-Config File gespeichert Liste von Servern ist in einer app.config (XML) eingetragen SpielerID(1,2,3,4) SpielerName = frei wählbar © 2009 FH Technikum Wien


Herunterladen ppt "Projekt Alcatraz Java RMI / Spread - Gruppe A4."

Ähnliche Präsentationen


Google-Anzeigen