49 lines
3.3 KiB
Markdown
49 lines
3.3 KiB
Markdown
# Game of Life über mehrere Monitore
|
|
|
|
Implementierung des berühmten [Conway's Game of Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) als verteiltes System.
|
|
Jeder Teilnehmer hat einen Bereich in dem er Game of Life berechnet und seine Kanten mit den andren Teilnehmer austauscht.
|
|
Die gesamte Koordination erfolgt dezentral, Kommunikation ist immer p2p-basiert.
|
|
|
|
|
|
## Einstieg
|
|
Um an dem Spiel teilzunehmen, muss jeder Teilnehmer (außer der erste) beim Starten der Anwendung die IP-Adresse und den
|
|
Port eines anderen Teilnehmers angeben, mit dem er sich verbinden will.
|
|
Zusätzlich muss die Richtung der Kante, mit welcher er sich mit diesem verbinden will, angegeben werden.
|
|
Da jeder Teilnehmer an jeder seiner Kanten maximal mit einem anderen Teilnehmer verbunden sein kann, ist es möglich,
|
|
dass die Kante, die beim Einstieg gewählt wird, bereits besetzt ist.
|
|
Ist dies der Fall, wird der Anfragende automatisch an denjenigen weitergeleitet, der diese Kante besetzt.
|
|
Dies passiert so lange bis eine freie Kante gefunden wird und sich somit zwei Teilnehmer verbinden.
|
|
Wenn man sich also **rechts** von Teilnehmer 1 verbinden will, ist es nicht garantiert, dass man direkt mit Teilnehmer 1
|
|
verbunden wird, sondern nur, dass man räumlich **rechts** von Teilnehmer 1 liegt.
|
|
|
|
|
|
|
|
## Suche
|
|
Die Suche ist recht simpel.
|
|
Jeder Teilnehmer kennt nur die Knoten, welche die für ihn relevanten Informationen haben und diese verändern sich im Laufe
|
|
der Zeit auch nicht.
|
|
|
|
## Verbreitung
|
|
Eine relevante Information, die an das gesamte Netz verbreitet werden muss, ist eine Zustandsänderung bezüglich der
|
|
Pausierung der Simulation.
|
|
Hierfür wird einfaches Flooding verwendet.
|
|
D.h. jeder Teilnehmer schickt den neuen Zustand an alle seine Nachbarn und diese senden ihn wiederum an ihre Nachbarn.
|
|
Da es nur zwei mögliche Zustände für den Pause-Zustand geben kann, ist Flooding ausreichend effizient, zyklische Nachrichten
|
|
werden vermieden, indem ein Teilnehmer die Information nicht mehr weiterleitet, wenn er sie bereits bekommen hat, sich also
|
|
schon im richtigen Zustand befindet.
|
|
|
|
## Zeitliche Synchronisation
|
|
Um sicherzustellen, dass alle Teilnehmer gleichzeitig den Entwicklungsschritt durchführen und somit der Randaustausch auch
|
|
korrekt funktioniert, wird eine vereinfachte Version von Lamport Clocks verwendet.
|
|
Jeder Prozess hat einen Counter, den er bei jedem Entwicklungsschritt um eins erhöht.
|
|
Da für jeden Entwicklungsschritt zuerst die Ränder der benachbarten Teilenehmer abgefragt werden müssen und dies blockieriend geschieht, sind alle Teilnehmer zu jedem Zeitpunkt um maximal 1 bezüglich ihres Counters versetzt.
|
|
Damit man jedoch mit seinem Entwicklungsschritt nicht warten muss, bis alle Nachbar den Rand angefragt haben, hält jeder Prozess eine Kopie seine Randes vom vorherigen Zeitpunkt.
|
|
Bei der Anfrage nach dem Rand wird der nachgefragte Counter mitgeschickt, dieser muss dem aktuellen oder dem vorherigen Counter entsprechen oder um eins größer sein, als der aktuelle Counter.
|
|
Ist der angefragte Counter um eins größer als der aktuelle, liegt also quasi in der Zukunft, wird der Request blockiert, bis der Angefragte den nächsten Entwicklungsschritt durchgeführt hat.
|
|
Somit wird das gesamte Game of Life nur so schnell ausgeführt, wie der langsamste Teilenehmer ist.
|
|
|
|
|
|
|
|
<!-- LocalWords: Counter
|
|
-->
|