Alcatraz - Versionsgeschichte

Reini: /* Gesamt-Ablauf als Sequenz-Diagramm */

2011-05-03T20:42:37Z

Gesamt-Ablauf als Sequenz-Diagramm

← Nächstältere Version		Version vom 3. Mai 2011, 20:42 Uhr
Zeile 120:		Zeile 120:
	== Gesamt-Ablauf als Sequenz-Diagramm ==		== Gesamt-Ablauf als Sequenz-Diagramm ==

	[[Datei:~~Registrierung_700~~.jpg]]		[[Datei:RegisterRequest_700.jpg]]

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

Reini: /* Gesamt-Ablauf als Sequenz-Diagramm */

2011-05-03T20:33:00Z

Gesamt-Ablauf als Sequenz-Diagramm

← Nächstältere Version		Version vom 3. Mai 2011, 20:33 Uhr
Zeile 120:		Zeile 120:
	== Gesamt-Ablauf als Sequenz-Diagramm ==		== Gesamt-Ablauf als Sequenz-Diagramm ==

	[[Datei:~~Registrierung~~.jpg]]		[[Datei:Registrierung_700.jpg]]


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

Reini: /* Klassen-Diagramme Server */

2011-05-03T20:32:25Z

Klassen-Diagramme Server

← Nächstältere Version		Version vom 3. Mai 2011, 20:32 Uhr
Zeile 79:		Zeile 79:

	=== Klassen-Diagramme Server ===		=== Klassen-Diagramme Server ===
	[[Datei:~~Alcatraz_Server~~.jpg]]		[[Datei:Server_700.jpg]]

	= Spezifikation des Ablaufs zwischen Client und Registrierungsserver zum Starten des Spiels =		= Spezifikation des Ablaufs zwischen Client und Registrierungsserver zum Starten des Spiels =

Reini: /* Ablauf der Kommunikation zwischen den RegistryServern bzw. zwischen Coordinator und RegistryServer */

2011-05-03T20:31:45Z

Ablauf der Kommunikation zwischen den RegistryServern bzw. zwischen Coordinator und RegistryServer

← Nächstältere Version		Version vom 3. Mai 2011, 20:31 Uhr
Zeile 68:		Zeile 68:

	=== Ablauf der Kommunikation zwischen den ''RegistryServer''n bzw. zwischen ''Coordinator'' und ''RegistryServer'' ===		=== Ablauf der Kommunikation zwischen den ''RegistryServer''n bzw. zwischen ''Coordinator'' und ''RegistryServer'' ===
	[[Datei:~~Message_Flow~~.jpg]]		[[Datei:MessageFlow_700.jpg]]

	=== Spread Messages ===		=== Spread Messages ===

Reini: /* Protokoll der Präsentation vom 9.3.2011 */

2011-04-25T20:27:10Z

Protokoll der Präsentation vom 9.3.2011

← Nächstältere Version		Version vom 25. April 2011, 20:27 Uhr
Zeile 228:		Zeile 228:

	[[Kategorie:FH]]		[[Kategorie:FH]]

	~~= Protokoll der Präsentation vom 9.3.2011 =~~

	~~'''Frage Froihofer:''' wodurch kommt der Name zustande, unter dem der Client in der Registry gebunden wird? (Folie 3)~~
	*AW: kommt noch

	~~'''Frage Froihofer:''' RMI Registry außerhalb von Server und Client gezeichnet? (Folie 4)~~
	*AW: jeder Server schreibt lokal in sein Registry Server Object

	~~'''Frage Froihofer:''' dh bei Ausfall des Koordinators ist der Client dafür zuständig, neu zu registrieren? Wer könnte feststellen dass er gecrashed ist?~~
	*AW: wenn der Client direkt auf den Koordinator geht, gibt es keine andere Möglichkeit. Ist einer dazwischen, könnte der einfach an den neuen Koordinator weiterleiten

	~~'''Frage Froihofer:''' woher wissen wir (Interfaces), welche ID wir verwenden müssen?~~
	*Aw: die eindeutige Spieler ID wird von Registration Object zurück gegeben

	~~'''Frage Froihofer:''' warum muss man das Registration Object in der Phase binden? Was steht in den Backup Messages?~~
	*AW... ausreichend offenbar :D

	~~'''Frage Froihofer:''' warum 2 Methoden accept, deny und nicht gleich über das Registration Object weitergeben? Was passiert, wenn genau da das Netzwerk weg ist?~~
	*AW: er würde darüber nachdenken, es direkt ins Registration Object hineinzugeben, dann ist ein Request weniger.

Reini: /* Ablauf der Kommunikation zwischen den RegistryServern bzw. zwischen Coordinator und RegistryServer */

2011-04-25T19:20:11Z

Ablauf der Kommunikation zwischen den RegistryServern bzw. zwischen Coordinator und RegistryServer

← Nächstältere Version		Version vom 25. April 2011, 19:20 Uhr
Zeile 69:		Zeile 69:
	=== Ablauf der Kommunikation zwischen den ''RegistryServer''n bzw. zwischen ''Coordinator'' und ''RegistryServer'' ===		=== Ablauf der Kommunikation zwischen den ''RegistryServer''n bzw. zwischen ''Coordinator'' und ''RegistryServer'' ===
	[[Datei:Message_Flow.jpg]]		[[Datei:Message_Flow.jpg]]

			=== Spread Messages ===
			Der Nachrichtenaustausch erfolgt in Form serialisierter Objekte, die mithilfe von ''SpreadMessage'' Objekten versendet werden.

			Ordering der Spread Messages ist ''Fifo by Sender'', da zwar die Reihenfolge der Nachrichten pro versendende Instanz relevant ist, causal ordering aber nicht erforderlich (Koordinator).

	=== Paket Diagramm ===		=== Paket Diagramm ===

Reini: /* Spezifikation der Mechanismen um Serverausfälle tolerieren zu können */

2011-04-24T17:59:13Z

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

← Nächstältere Version		Version vom 24. April 2011, 17:59 Uhr
Zeile 137:		Zeile 137:
	* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.		* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.
	* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State an neue Mitglieder der Multicast Gruppe.		* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State an neue Mitglieder der Multicast Gruppe.
	* Jeder Server verwaltet ~~alle~~ noch nicht beantworteten oder abgearbeiteten ''Request'' ~~Objekte~~. ~~Wird ein~~ ''Response'' ~~Objekt erhalten,~~ wird das ~~entsprechenden~~ ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.		* Jeder Server verwaltet eine Liste mit noch nicht beantworteten oder abgearbeiteten ''Request'' Objekten. Bei Erhalt eines ''Response'' Objekts wird das korrespondierende (über systemweite Objekt Identifizierer) ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.
	* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.		* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.

Reini: /* Spezifikation der Mechanismen um Serverausfälle tolerieren zu können */

2011-04-24T17:56:52Z

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

← Nächstältere Version		Version vom 24. April 2011, 17:56 Uhr
Zeile 136:		Zeile 136:
	* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.		* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.
	* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.		* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.
	* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State ~~bei~~ an neue Mitglieder der Multicast Gruppe.		* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State an neue Mitglieder der Multicast Gruppe.
	* Jeder Server verwaltet alle noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.		* Jeder Server verwaltet alle noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.
	* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.		* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.

Reini: /* Spezifikation der Mechanismen um Serverausfälle tolerieren zu können */

2011-04-24T17:56:19Z

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

← Nächstältere Version		Version vom 24. April 2011, 17:56 Uhr
Zeile 136:		Zeile 136:
	* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.		* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.
	* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.		* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.
			* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State bei an neue Mitglieder der Multicast Gruppe.
	* Jeder Server verwaltet alle noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.		* Jeder Server verwaltet alle noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.
	* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State bei Bedarf als Multicast Message an alle Server.
	* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.		* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.

Reini: /* Spezifikation der Mechanismen um Serverausfälle tolerieren zu können */

2011-04-24T17:54:57Z

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

← Nächstältere Version		Version vom 24. April 2011, 17:54 Uhr
Zeile 136:		Zeile 136:
	* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.		* jeder Server hat eine lokale RMI Registry. Die RMI Registries der Server sind synchron.
	* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.		* das ''RegistryServer'' Objekt ist redundant. Registrierungen eines Clients werden über ein mit Spread implementiertes Primary-Backup Protokoll repliziert.
	* Jeder Server ~~hat eine lokale Kopie der~~ noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.		* Jeder Server verwaltet alle noch nicht beantworteten oder abgearbeiteten ''Request'' Objekte. Wird ein ''Response'' Objekt erhalten, wird das entsprechenden ''Request'' Objekt aus der Liste entfernt. Neue Koordinatoren arbeiten die Liste mit den offenen Requests (z.B. Registrierungen, Unregister-Requests, Übergabe von ''GameClient'' Objekten) ab. Weiters wird der Status noch ungestarteter Spiele von neuen Koordinatoren geprüft und entsprechend gehandelt.
	* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State bei Bedarf als Multicast Message an alle Server.		* Ein Koordinator ist jederzeit vorhanden. Dieser sendet seinen State bei Bedarf als Multicast Message an alle Server.
	* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.		* Server, die der Multicast Gruppe beitreten (nach crash wieder verfügbar, oder neuer Server), synchronisieren die lokale RMI Registry mit jener des als Koordinator fungierenden Servers. Erst dann sind sie vollwertiges (und von Clients nutzbares) Mitglied der Multicast-Gruppe.