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.

8.1 Umgesetzte Anforderungen im Einzelnen

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.

8.1.1 Einfachheit

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.

8.1.2 Sicherheit

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.

8.1.3 Konsistenz

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.

8.1.4 Skalierbarkeit und Performanz

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.

8.1.5 Wirtschaftlichkeit

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.

8.2 Offene Probleme und Verbessungsmöglichkeiten

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.

8.2.1 Optimierung des Netzwerktraffics

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.

8.2.2 Umfangreichere Performanztests

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.

8.2.3 Unterstützung weiterer Programmiersprachen

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.

8.2.4 Erweiterung des zentralen Servers

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.

8.2.5 Schaffung von trusted RegionControllern

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.

8.2.6 Tools zur Speicherung der Datenstrukturen

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/

Menü

Home
Funstuff
Linux
Hardware
Distributionen
Spiele
Kontakt
Projekte
Java
Webcut
Strength and Honor
A-Mobile
Holy-Wars 2
Holy-Wars 3
-> Dokumentation
Biometrie
Performanzermittlung
-> Mmpg
-> Mmpg-peer to peer
Javadoc
Mmpgp2p-Server
Semantic Web
WSA