Subsections
8. Zusammenfassung und Ausblick
Ziel der Diplomarbeit war die Schaffung eines P2P-Systems für MMPGs. Das Themengebiet umfasst
sehr viele Bereiche und ist durch eine einzelne Diplomarbeit nicht abzudecken. Dies wurde
bereits in der frühen Phase erkannt und daher ein Kompromiss gesucht,
um ein grundsätzlich lauffähiges und leicht erweiterbares System zu entwickeln und vorzustellen.
Das vorgestellte Framework setzt diesen Kompromiss um und demonstriert den Großteil der
theoretischen Überlegungen in der Praxis. Bei der Entwicklung der Klassenhierarchie wurde
darauf Wert gelegt, dass sie leicht zu ergänzen und zu erweitern ist. Funktionen, die
theoretisch ausgearbeitet, jedoch im Framework nicht umgesetzt wurden, sind im
Quellcode berücksichtigt und vorbereitet.
Diese Arbeit und das entwickelte Java-Framewörk können als Grundlage für weitere Forschung
dienlich sein. Die ausführliche Dokumentation der Java-Klassen und die theoretische Ausarbeitung
der wichtigsten Apsekte in dieser Arbeit machen dies möglich.
Da in den Leistungstests der Server nicht voll ausgelastet werden konnte, weil einfach Rechenleistung für
noch mehr Clients gefehlt hat, können keine verlässlichen Aussagen über die Skalierung mit
sehr vielen Clients getätigt werden. In der vorliegenden Testumgebung lief der Server stabil.
Zu Anfang dieser Ausarbeitung wurden einige Anforderungen an ein Framework gestellt (siehe 2.3.1),
die zum größten Teil mit der vorliegenden Arbeit und dem Prototyp des Frameworks umgesetzt wurden.
Auf die einzelnen Anforderungen werde ich nun noch einmal eingehen und aufzeigen, ob und
wie sie erzielt wurden.
Die Verwendung des Frameworks wurde mit dem Tutorial in Kapitel 6.2) erläutert und sollte
einem Programmierer kaum Probleme bereiten. Die Menge an Code, der für eine lauffähige Implementierung notwendig ist,
bleibt in überschaubarem Rahmen.
Der Programmierer benötigt prinzipiell keinerlei Kenntnisse in der Verwendung
von Sockets oder sonstigen Netzwerktechniken. Für den Programmierer existieren nur Funktionen zum Absenden
eines Kommandos und zur Verarbeitung selbst definierter Kommands über die Klasse Ruleset. Diese
Funktionen wurden gut dokumentiert und deren Verwendung ist intuitiv.
Da der Quellcode als Open Source vorliegt, sind Anpassungen an eigene Bedürfnisse sowie Weiterentwicklungen
problemlos möglich, sofern der Entwickler die notwendige Kompetenz aufweist. Die gut ausgearbeitete JavaDOC
ist dafür eine gute Basis. Das Ziel Einfachheit bei der Verwendung wurde also erreicht.
Sensible Daten werden nur auf dem Server hinterlegt und verarbeitet. Diese sind also so sicher,
wie es der Server ist. Login- und Personenbezogene Daten verlassen niemals den Server
und sind somit auch keinen Mißbrauchsversuchen ausgesetzt. Der Betreiber kann die Kunden
leicht abrechnen, indem er entspechenden Code in die Implementierung der Login-Funktion
aufnimmt. Denkbar wäre z.B. der Einsatz einer (externen) Datenbank, zu der man per JDBC
verbindet und die Benutzerdaten speichert sowie Login und Logout protokolliert.
Cheating von Spielern wird sich theoretisch nie ganz ausschließen lassen. Jedoch sind die
Möglichkeiten für die Beteiligten sehr gering. In der vorgestellten Architektur steigt die
Sicherheit des Systems theroretisch mit der Anzahl der RegionController im RCPool einer Region.
Im Vorfeld wurde bereits festgelegt, dass das Abgleichen von Spielzügen und Ergebnissen
innerhalb des RCPools nicht implementiert wird. Vor allem müssen noch Techniken zur
Entscheidung über gültige Spielzüge der Clients und über gültige Modifikationen
der RegionController auf ihrer Teilwelt geschaffen werden. In der vorliegenden Implementierung wird nicht überprüft, ob
jeder RegionController gleiche Ergebnisse erzielt und ebenso wenig wird auf der Seite
des Clients überprüft, ob alle RegionController diesselben Updates zurückgeliefert haben.
Dies war im Vorfeld bereits bekannt und wurde nicht zum Umfang dieser Arbeit erklärt,
obgleich die Vorraussetzungen für eine solche Erweiterung bereits geschaffen wurden.
Daher sind nachfolgende Annahmen theroretischer Natur. Mit der Möglichkeit der
direkten Einstellung von Parametern durch den Administrator
des Servers wäre gewährleistet, dass der Betreiber einen für sich
optimalen Kompromiss zwischen Cheatresistenz und Performanz finden kann.
Sollten die geforderten Erweiterungen implementiert werden, dann gewährleistet das System
theroetisch ein moderates Level an Sicherheit. Eine realistische Einschätzung kann jedoch
noch nicht abgegeben werden.
Durch die Implementierung eines RCPools zur Kontrolle einer Region wurden erste
Vorraussetzungen geschaffen, um die Konsistenz der Daten zu wahren und gegen Ausfälle zu schützen.
Es wurden noch keinerlei Schutzvorkehrungen gegen Datenverluste implementiert,
die natürlich direkt in inkonsistente Zuständen führen würden. Die Erweiterung der
RegionController um Funktionen zur regelmäßigen Speicherung der Daten sollte in
einer weiterführenden Arbeit kein Problem darstellen. Die Erarbeitung und Implementierung
einer solchen Funktionalität gehörte jedoch nicht zum Umfang dieser Arbeit.
Das System wurde leider noch nicht im Betrieb mit vielen (menschlichen) Spielern
getestet, deren Systemen unvorhergesehene Verhaltensweisen an den Tag legen könnten.
Das entwickelte Spiel stellt nur einen kleinen Funktionsumfang zur Verfügung
und animiert kaum jemandem zum Testen. Somit sind die genannten Eigenschaften
eher theoretischer Natur und müßten durch weitere und umfangreichere Tests verifiziert werden.
Theoretisch wird Konsistenz gewährleistet, in der Praxis ist es jedoch nicht erprobt.
Im Rechnerpool des Fachgebietes ``Datenbanken und Verteilte Systeme'' wurden einige automatisierte
Tests durchgeführt. Nebenbei wurden regelmässig kleinere Tests mit echten Spielern durchgeführt,
um die Spielbarkeit zu überprüfen. Der Server wurde zwar des Öffteren ausgelastet, wenn mehrere
Clients gleichzeitig dem System beitreten wollten, doch dies führte nicht Fehlern.
Durch die Implementierung des RegionControllers als unabhängig laufender Prozess
(RegionControllerThread) bietet sich die Möglichkeit, das System dynamisch mit zusätzlicher Rechenzeit
in Form von eigentständig startenden RegionControllern zu versorgen.
8.1
Eine Obergrenze an durch den Server bedienbaren Clients wurde durch das Testsystem nicht gefunden. Leider
war es ab einer gewissen Anzahl an Clients pro Pool-Rechner (BotPlayer) nicht mehr möglich, weitere Instanzen zu starten,
da diesen Systemen Rechenleistung fehlte. Der Server skalierte gut mit der Anzahl der verbundenen Clients,
über das Verhalten bei deutliche mehr als 200 Clients lassen sich jedoch keinen zuverlässigen Aussagen
treffen. Hierfür wären deutlich mehr als die zur Verfügung stehenden Pool-Rechner nötig.
Das vorgestellte System beansprucht vor allem die Rechenzeit der RegionController. Der Server wird nur für Login und Datensicherung
sowie für einfache Informationsdienste benötigt, welche kaum Systemlast verursachen sollten. In meiner Testumgebung
wurde der Server auf einem einfachen, handelsüblichen System gestartet, das natürlich keinerlei Ausfallsicherungen
bereithält, jedoch für unter 1000 EUR zu haben sein sollte.
Durch den Einsatz von JAVA ist das System nicht an eine Hardware-Architektur gebunden. Dem Einsatz auf einem
ausfallsicheren, angemieteten Mainframe steht nichts im Wege, sofern JAVA auf dem System verfügbar ist.
Somit sollten die Kosten für den Betrieb eines MMPGs mit dem vorgestellten Framework überschaubar und gering ausfallen.
Die niedrige Anschaffungs- und Wartungskosten gewährleisten somit Wirtschaftlichkeit des vorgeschlagenen
Systems.
Ein weiterer, durchaus wichtiger Punkt ist die Tatsache, dass ein Entwickler mit
diesem Framework eine Technik verwenden kann, die nur kurze Einarbeitungszeit benötigt. Wie bei Punkt
Einfachheit erläutert, sind keine umfangreichen Kenntnisse von Netzwerktechnik nötig,
um das System einsetzen zu können. Dies spart zusätzliche Entwicklungskosten.
Während der Arbeit am Framework wurden einige Kompromisse eingegangen und gezielt
auf einzelne Details verzichtet, weil der zeitliche Rahmen die Ausarbeitung nicht zulies.
Nachfolgend werden kurz einige Punkte auflisten, die wichtig für weitere Arbeiten sind.
Ein Kritikpunkt ist, dass durch die Übermittlung von kompletten Objekten nach ihrer
Änderung sehr viel Traffic produziert wird. Setzt die Anwendung auf komplexe Objekte mit
vielen Eigenschaften, dann werden die meisten Daten und Eigenschaften übermittelt,
obwohl sie sich garnicht geändert haben. Hinzu kommt, dass ich für die Übermittlung von Daten
ObjectOutputStream verwendet habe, was zusätzlichen Overhead erzeugt.
Während der Tests mit menschlichen Spielern auf dem DSL-System wurde oft die maximale Bandbreite
der DSL-Anbindung erreicht, weshalb eine einfach Komprimierung des Datenstroms implementiert
wurde. Die RegionController komprimieren die Objekt-Updates mit GZIP (beschrieben in Abschnitt 5.5.6.5),
wodurch die übermittelten Daten auf weniger als die Hälfte schrumpfen. Bei einer Übertragungsrate von
20KB/S wurde durch die Aktivierung der GZIP-Kompression eine Verbesserung auf 10KB/S erreicht.
Wünschenswert wäre daher die Übertragung einer Art Delta der Objekt-Eigenschaften.
Dieses Vorgehen kennt man bereits von Programmen wie rsync oder patch.
Vorteil dieser Verbesserung wäre die Einsparung von Traffic und damit langfristig effizientere
Auslastung der Netzwerkressourcen. Für die Berechnung eines Deltas zu einem Objekt jedoch wird
Rechenleistung benötigt, welche die Last auf den RegionControllern erhöht.
In der Regel verursachen Delta-Verfahren mehr Last beim Erzeugen des Delta als beim
Anwenden, weshalb auf der Seite des Clients weitaus weniger Last zu erwarten ist.
Hierfür muss ein Kompromiss gefunden werden.
Die durchgeführten Testreihen wurden allesamt durch die Verfügbare Rechenleistung auf Seiten der
Clients beschränkt. Die Testsysteme konnten ab einer gewissen Anzahl von simulierten Clients
nicht mehr stabil arbeiten. Der eingesetzte Server ``delhi'' wurde nicht bis an seine Grenzen
ausgelastet und lief stabil weiter.
Die Implementierung von aufwändigen Spielen in Java ist in der Softwareindustrie nicht
üblich. Gängig sind nach wie vor C/C++ basiert Spiele mit Konzentration auf die grafische Oberfläche.
Es wäre daher sinnvoll, wenn für C/C++ und andere wichtige Programmiersprachen Schnittstellen
zur Verfügung stünden, oder das MmpgP2P-System gar nativ in solchen Sprachen umgesetzt würde.
Letzteres hätte den großen Vorteil, dass auf die Installation eines Java Runtime Enviroments (JRE)
verzichtet werden kann.
Als einfachste Erweiterung wäre eine Schnittstelle zwischen den Java-Threads und anderen
Programmen sinnvoll. Denkbar wäre die Kommunikation über Sockets.
Ein kritischer Punkt im System ist immernoch die Zentralisierung des System um den Server
herum. Durch den Ausfall des Servers wäre zwar eine Fortführung des Spiels möglich, doch könnten
keine Clients mehr beitreten und es würden mit der Zeit ein Mangel an RegionController entstehen.
Falls in einer Region alle RegionController ausfallen oder das System verlassen, wären die
Änderungen verloren.
Durch Erweiterung des Servers auf eine Art Server-Pool und Dezentralisierung der Funktionen,
die der Server übernimmt, könnte zusätzliche Ausfallsicherheit gewonnnen werden.
Trusted RegionController sind RegionController, denen das System vertraut. Wird
ein trusted RegionController einer Region zugewiesen, dann werden keine weiteren
RegionController für diese Region benötigt.
Im vorgestellten System gibt es lediglich einen RegionController, dem der Server
blind vertraut. Dies ist der initiale RegionController, der vom Server gestartet wird. Bei
hoher Last verliert dieser RegionController jedoch die Kontrolle über einen Großteil
der Welt.
Es ist wünschenswert, dass das System eine Möglichkeit bietet, dem Netzwerk weitere
trusted RegionController bereitzustellen, die ebenso vertrauenswürdig wie der initiale
RegionController des Servers sind. Optimalerweise ließe sich die Zuweisungen dieser RCs zu bestimmten
Regionen steuern, um z.B. eine Stadt oder einen stark frequentierter Bereich der Spielewelt
durch diese vertrauenswürdigen RegionController zu steuern. Im Abschnitt
wurde zwar ein StandaloneRC beschrieben, dieser kann jedoch von beliebigen Systemen
gestartet werden und ist daher nicht vertrauenswürdig.
Die Verfügbarkeit von trustet RegionControllern würde die Performanz in manchen Regionen deutlich erhöhen,
weil sich die Clients dann nur mit einem einzigen RegionController verbinden müssen.
Und weil man davon ausgehen kann, dass ein solcher trusted RegionController dem System für
lange Zeit zur Verfügung steht, steigt die Ausfallsicherheit dieser Region. Natürlich ist
diese Ausfallsicherheit nur dann gegeben, wenn der trusted RegionController auf einem
System gestartet wird, dass stabil läuft.
Innerhalb der Klasse ServerThread existieren einige Methoden, die dem Endanwender
das Laden bzw. die Speicherung von Daten nahelegen. Für die Darstellung von Objekten,
Avataren oder gar der gesamten Spielewelt sind jedoch bisher keinerlei externe Datenstrukturen
vorhanden. Es wäre also wünschenswert, einige Tools zu entwickeln, die das Laden und
permanente Speichern von Daten des Systems auf der Festplatte (z.B. über XML-Dateien)
oder in Datenbanken zulassen.
http://www.psitronic.de/ti/mmpg/mmpg-peer_to_peer/
|
|