Next: 6. Verwendung des Frameworks Up: MMPG-P2P Previous: 4. Das Framework ``MMPGP2P''   Contents   Index

• 5.1 Entwicklungsumgebung
  • 5.1.1 Programmiersprache
  • 5.1.2 Buildumgebung
  • 5.1.3 Testumgebung
  • 5.1.4 Dokumentation
  
  
• 5.2 Konfigurationdateien
  • 5.2.1 Beispiel einer Properties-Datei
  • 5.2.2 Weitere Parameter
  
  
• 5.3 Wichtige Klassem
  • 5.3.1 Ruleset
  • 5.3.2 abstrakten Methoden
  • 5.3.3 GameWorld und GameObject
  • 5.3.4 GameWorldInfo und RegionInfo
  • 5.3.5 RCPool
  • 5.3.6 RegionTree
    • 5.3.6.1 Operationen
  
  
• 5.4 Programmablauf und Datenfluß
  • 5.4.1 Login
  • 5.4.2 Spielstart
  • 5.4.3 Hauptschleife: Spielzüge und Spielwelt-Updates
  • 5.4.4 Wechseln der Region
  • 5.4.5 Logout
  • 5.4.6 Splitting einer Region
  • 5.4.7 Serververbindungen
  
  
• 5.5 Beschreibung wichtiger Klassen
  • 5.5.1 MmpgP2PCommand
  • 5.5.2 SessionTicket
  • 5.5.3 MmpgP2PServiceThread
    • 5.5.3.1 Abstrakte Methoden
    • 5.5.3.2 Sonstige wichtige Methoden
  • 5.5.4 ConnectionListenerThread
  • 5.5.5 ConnectionWorkerThread
  • 5.5.6 RegionControllerThread
    • 5.5.6.1 Funktionsweise
    • 5.5.6.2 Interner Aufbau
    • 5.5.6.3 Hauptschleife und Ticks
    • 5.5.6.4 Kommunikation mit Clients
    • 5.5.6.5 GZIP-Komprimierung
  • 5.5.7 ClientThread
    • 5.5.7.1 Implementierungen
    • 5.5.7.2 Ablauf eines Logins
    • 5.5.7.3 Senden von benutzerdefinierten Kommandos
  • 5.5.8 RCQueueWorkerThread
  • 5.5.9 ServerThread
    • 5.5.9.1 Protokollierung von Server-Statistiken
  
  
• 5.6 HTTP-Schnittstelle
  • 5.6.1 Login über HTTP
  • 5.6.2 Kommandos

5. Java-Umsetzung

5.1 Entwicklungsumgebung

5.1.1 Programmiersprache

Zum einen unterstützt JAVA eine Vielzahl von Hardware-Architekturen und Betriebssystemen. Einmal entwickelt lässt sich der Code meist problemlos auf allen von JAVA unterstützten Systemen einsetzen. Der Nachteil dieser Technik ist, dass ein Interpreter benötigt wird, der auf den Zielsystemen installiert sein muß. Bei der Entwicklung eines Spieles muß dies berücksichtigt werden.

Zum anderen unterstützt das JAVA-SDK eine große Anzahl von Techniken, die für dieses Projekt wichtig sind. Die einfache Handhabung von Threads und Sockets hat die Entwicklung enorm erleichtert.

JAVA wurde in der Version 1.4.2 eingesetzt.

5.1.2 Buildumgebung

5.1.3 Testumgebung

Als MMPGP2P-Server kam mein Rechner ``anaconda'' zum Zuge, ein AMD Athlon(tm) XP 2200+ mit DSL-Anbindung und fester IP-Adresse 213.146.116.174. Der Server läuft ebenfalls unter Debian GNU/Linux 3.1-Sarge mit Kernel 2.4.27. Ich habe den MMPGP2P-Server ständig auf diesem System laufen lassen und nur während der Weiterentwicklung der Klassen neu gestartet.

Für die Simulation von Clients habe ich zum einen meinen Rechner ``media'' eingesetzt, eine Multimedia-Station mit Intel(R) Pentium(R) 4 CPU 2.40GHz und 100MBit-Netzwerkanbindung an den Server. Auf diesem System lief Debian GNU/Linux 3.1-Sarge allerdings mit Kernel 2.6.11.6. Als weitere Clients kamen diverse Testumgebungen unter VMware Workstation 3.2.0 build-2230 zum Einsatz, darunter Windows XP und Windows 98.

Weiteres ist im Kapitel 7 über Performanzmessungen beschrieben.

5.1.4 Dokumentation

5.2 Konfigurationdateien

Da am MMPGP2P-System im Prinzip drei Parteien beteiligt sind, nämlich Client, Server und RegionController, werden die Parameter entsprechend benannt. Anstatt eines Parameters port gibt es somit rc.port und server.port. Ein Vorteil dieser Konvention ist, dass man eine einzige Properties-Konfigurationsdatei für alle drei Teile verwenden kann. Hier ist jedoch Vorsicht angebracht, weil unter Umständen der RegionController des Servers mit dem RegionController eines Clients auf demselben Rechner in Konflikt geraten kann.

5.2.1 Beispiel einer Properties-Datei

# ---- Hier beginnt der Teil für Server ---- #
# Hostname und Port des Servers konfigurieren. Diese Informationen
# stehen dann u.a. in den SessionTickets für die Clients.
server.hostname = www.mmpgp2p.org
server.port     = 18987
# backlog gibt die maximale Anzahl wartender Clients an
# Siehe Java Dokumentation zur Klasse java.net.ServerSocket
server.backlog  = 100

# Der nicename taucht in Protokollen oder SessionTickets auf und
# kann benutzt werden, um zusätzliche Individualität zu verleihen.
server.nicename = MMPGP2P Prototype Server

# Ping an Clients alle 60 Minuten
server.ping_interval = 60000

# Server Debugging-Ausgaben aktivieren
server.debug=1

# Die Ausgaben des Servers in folgende Datei umleiten
server.log_file = server.log


# Der Server kann regelmäßig seine Status protokollieren. Mit diesem
# Parameter gibt man die Zieldatei für die Protokolle an.
server.stats.log_file = server.stats

# append steurt, ob die Protokolle angehängt werden sollen, oder ob der 
# Server die Datei überschreiben soll. Standard ist überschreiben.
server.stats.append   = 0

# Intervall in ms, in dem Stats in die Datei geschrieben werden.
server.stats.inverval = 5000


# HTTP-Interface aktivieren und admin-Passwort setzen
server.http.active = 1
server.http.adminpassword = secret

# Auf der HTTP-Oberfläche wird ein RegionTree grafisch dargestellt. 
Mit diesem Parameter kann man den Zoom einstellen. Wert in 1/1000.. 
server.http.region_tree_zoom = 20

# ---------------------------------------------------- #
# ---- Hier beginnt der Teil für RegionController ---- #

# Hostname und Port, auf dem der RegionController nach eingehenden 
# Verbindungen lauscht. Für Clients-Systeme empfielt sich hier ein
# Port, der nicht durch eine Firewall geblockt wird.
rc.hostname = me.home.org
rc.port     = 18900

# Der nicename taucht in Protokollen auf und kann benutzt werden, um
# dem RC zusätzliche Individualität zu verleihen.
rc.nicename = Me RC Nr. 1

# RegionController Debugging-Ausgaben aktivieren
rc.debug=1

# Die Spielewelt aus folgender Datei laden
rc.game_world_file=/tmp/initial.world

# Start-Timeout des RCs in ms
rc.start_timeout = 30000

# Logfile für RegionController (Ausgabe in Datei anstatt System.out)
rc.log_file = /tmp/rc.log

# Grenzwerte für die Benutzung der Region
rc.maxclients = 15
rc.minclients =  1

# ------------------------------------------ #
# ---- Hier beginnt der Teil für Client ---- #
# Debugging auch für den Client aktivieren
client.debug = 1

# Noch mehr Debugging. Falls hier 1 eingestellt wird, dann werden
# die Befehle in der Sende- und Empfangs- Warteschlange ausgegeben.
client.log_queue_commands = 0

# Logging aller Kommandos, die vom Client ausgeführt werden
client.debug_execute_commands = 0

# Benutzername und Passwort, das der Client beim Authentifizieren benutzt
client.username = testusr
client.password = mysecret


# Die Grösse der zufällig erzeugten TestGameWorld und
# deren tilesize konfigurieren
world.totx=100000
world.toty=100000
world.tilesize=1000

Die Beispielimplementierung (siehe 6.2) unterstützt das Einlesen von solchen Konfigurationsdateien aus dem ``HOME''-Verzeichnis (für Unix-basierte Systeme) oder unter ``Dokumente und Einstellungen'' (für Windows-basierte Systeme) des aktuell angemeldeten Benutzers. Beim Starten von Client oder Server wird dann nach einer entsprechenden Datei client.rc oder server.rc im Ordner .mmpgp2p (Unix) oder mmpgp2p (Windows) unterhalb des Home-Verzeichnisses gesucht und geladen. Das Home-Verzeichnis wird durch die Java-Property ``user.home'' bestimmt.

5.2.2 Weitere Parameter

# Dieser Parameter teilt dem ClientThread mit, dass er die Kombination 
# username:password beim Server registrieren soll. In diesem Fall wird ein 
# REGISTER-Kommando abgesendet.
# Empfängt der Server dieses REGISTER-Kommando, dann wird seine Methode
# registerNewClient() aufgerufen.
# Der Implementierung steht es natürlich frei, die Registrierung proprietär
# und nicht über die entsprechende Methode im ServerThread zu implementieren.
client.register = 1

# Falls man einen Client ohne RC starten will, dann kann man diesen Wert 
# auf 0 setzen. Clients sollten allerdings immer einen RC starten.
rc.start    = 1

5.3 Wichtige Klassem

5.3.1 Ruleset

Für einen reibungslosen Betrieb des Systems sollten zunächst einige wichtige Punkte beachtet werden.

1. Niemals System.currentTimeMillis() für das Setzen von Zeitstempeln benutzen, da sich die Uhrzeiten auf verschiedenen Clients deutlich unterscheiden können, unter Umständen im Bereich von Minuten. Hierfür wurde die Methode getTime() (siehe Abschnitt 5.5.3.2 geschaffen, die auf allen Systemen zu einem bestimmten Zeitpunkt diesselben Werte liefert.
2. Niemals Math.random() für die Erzeugung von Zufallswerten benutzen. Alle RegionController in einem RCPool müssen bei gleichen Eingaben auch gleiche Ergebnisse erzielen, daher müssen auch die Zufallswerte bei allen RegionControllern gleich sein. Hierfür existiert eine Methode random() in der Klasse Ruleset.
3. Für neue Objekte niemals eine eigens gewählte ID setzen. Die Klasse GameObject bietet einen Konstruktor, dem eine Referenz auf GameWorld übergeben wird. Dieser sorgt für das Setzen einer systemweit eindeutige ID. Dieser Konstruktor fügt das neue Objekt noch nicht der Welt hinzu.
4. Avatare über die beiden Konstruktoren erzeugen und keinesfalls die ID modifizieren. Da ein Spieler mehrere Avatare besitzen kann, existieren für jeden Besitzer Avatar-IDs, die nur im Zusammenhang mit der ID des Spielers systemweit eindeutig sind (z.B. wenn Spieler 1 die Avatare mit ID 1 und 2 besitzen, kann Spieler 2 durchaus auch Avatare mit ID 1 und 2 besitzen). Die systemweit eindeutige ID eines Avatars wird aus der ID des Besitzers (owner) und der ID des Avatars für diesen Benutzer berechnet.

5.3.2 abstrakten Methoden

Alle Methoden müssen einen Array von GameObjects zurückliefern. In diesem Array sind alle von der Methode manipulierten Objekte enthalten. Das Ausliefern von Updates an die Clients ist abhängig davon, welche Objekte in diesen Array zurückgeliefert wurden.

• GameObject[] targetReached(GameWorld w, GameObject o)
  Diese Methode wird von der internen Bewegungsroutine aufgerufen, sobald ein Objekt sein Ziel rereicht hat. Die Beispielimplementierung sucht an dieser Stelle ein neues Ziel innerhalb der Grenzen der Teilwelt.
• GameObject[] applyCommand(GameWorld world, MmpgP2PCommand command)
  Sobald ein (User-) Kommando von einem Client empfangen wird, kommt diese Methode zur Ausführung. In der Regel werden durch diese Methode Befehle wie ``Gehe-Zu'' oder ``Feuere auf'' ausgeführt.
• GameObject[] doTick(GameWorld w, GameObject o)
  Diese Methode stellt die eigentliche Herausforderung an den Entwickler. In jedem Tick wird diese Funktion mehrfach aufgerufen, für jedes Objekt einmal. Da es durchaus geschehen kann, dass durch die Ausführung der Regeln auf ein Objekt mehrere andere Objekte manipuliert werden, wird hier ebenfalls ein GameObject[] zurückgegeben.

5.3.3 GameWorld und GameObject

Die Struktur GameWorld verwalten Objekte des Typs GameObject. Sie stellt Methoden zur Verfügung, über die Objekte innerhalb der Welt hinzugefügt, gelöscht, abgerufen oder manipuliert werden können. GameWorld enthält einen Zähler für die Vergabe von freien IDs. Beim Splitting einer Teilwelt wird dabei auch das Interval freier IDs auf die neu entstehenden Welten aufgeteilt. Objekte sollten daher stets über die von GameWorld zur Verfügung gestellten Operationen erzeugt werden, damit ihre ID nicht doppelt verwendet wird.

5.3.4 GameWorldInfo und RegionInfo

5.3.5 RCPool

Eine Methode sendToEach() erlaubt das Senden eines MmpgP2PKommandos an jeden der beinhalteten RegionController. Da die Klasse serialisierbar ist, kann man die Übertragung der Informationen eines RCPools einfach durch das Übertragen der Klasse RCPool über einen ObjectOutputStream erreichen.

5.3.6 RegionTree

Ein Blatt enthält Informationen über die Region selbst und die zugehörigen RegionController in Form einer Referenz auf einen RCPool (siehe 5.3.5). Nach einer Suche wird immer die Information eines Blattes zurückgegeben. Knoten speichern keine Referenzen.

Die Darstellung als binärer Suchbaum ermöglicht das effiziente Auffinden von Regionen zu einer (X;Y)-Koordinate. Beim Splitting einer Region wird das zugehörige Blatt zu einem Knoten mit zwei Blättern, die nun die zwei neuen Regionen darstellen.

5.3.6.1 Operationen

5.4 Programmablauf und Datenfluß

5.4.1 Login

Figure 5.1: Login des Clients

Das Login durchläuft einige Stationen, die hier der Reihe nach aufgelistet werden und die in Abbildung 5.1 grafisch dargestellt sind.

1. Der Client öffnet eine Verbindung zum Server
2. Der Client authentifiziert sich mit Benutzername und Kennwort
3. Der Server überprüft Benutzername und Kennwort
4. Der Server lädt die Avatare für den Client und erzeugt ein SessionTicket
5. Der Server öffnet Verbindungen zu den RCs des für den Client zuständigen RC-Pools
6. Der Server lädt die zum Client gehörigen Avatare und überträgt sie an den RC-Pool
7. Der Server trennt die Verbindungen zum RC-Pool und speichert, welchem RC-Pool er den Client zugewiesen hat
8. Der Server antwortet dem Client mit einem SessionTicket, das u.A. die zu kontaktierenden RegionController enthält
9. Der Client trennt die Verbindung zum Server
10. Der Client startet seine Befehls-Warteschlangen über die initCommandQueues-Methode. Diese Warteschlange hält Verbindung zum RC-Pool und dient als Schnittstelle zum Übertragen und Empfangen von MmpgP2PCommands.

Der Client ist nun mit seiner Region ``verbunden'' und kann mit dem Spiel beginnen.

5.4.2 Spielstart

In der Grafik 5.2 sind folgende Schritte skizziert:

1. Der Client erzeugt ein MmpgP2PCommand vom Typ START_GAME. Dieser wird an die RCs übertragen.
2. Der RC-Pool reagiert mit der Übertragung der Spielregeln (Ruleset)
3. Der RC-Pool überträgt die Spieler-Avatare
4. Der RC-Pool überträgt die für den Spieler sichtbare Welt
5. Der RC-Pool bestätigt dem Client, dass er nun regulär spielen kann

Nach der erfolgreichen Übertragung der Spielregeln, Avatare und der Spielewelt beginnt das eigentliche ``spielen''. Im folgenden Abschnitt wird der Ablauf dieses schleifenartiken Zykluses dargestellt.

5.4.3 Hauptschleife: Spielzüge und Spielwelt-Updates

Wird ein Objekt in der Welt des RegionControllers durch einen Spielzug geändert, dann wird es im nächsten Zyklus an alle Clients übertragen, die Zugriff auf das Objekt haben bzw. das Objekt besitzen, oder wenn sie das Objekt in Sichtweite (siehe 4.1.1.7) haben.

5.4.4 Wechseln der Region

1. Der Avatar wird über die Grenze der Region bewegt. Dies geschieht noch auf dem RegionController durch die Anwendung einer Bewegungsregel.
2. Der RegionController bemerkt, dass der Avatar seine aktuelle Region verlassen hat und initiiert den Regionswechsel für ihn.
3. Nun baut der RegionController eine Verbindung zum Server auf (oder benutzt eine noch offene Verbindung). Er übermittelt CHANGEREGION Kommando inklusive Avatar an den Server.
4. Nun pausiert er den Client, bis er vom Server eine Reaktion erhält.
5. Der Server sucht die zuständigen RegionController für die neue Region des Avatars. Er baut eine Verbindung zu diesen auf und übermittelt ihnen den Avatar des Spielers und das zugehörige Session-Ticket des Clients.
6. Die neuen RegionController erwarten nun die Verbindung des Clients.
7. Nun übermittelt er den alten RegionContollern ein CHANGEREGION Kommando, als Parameter werden die Session-ID des Clients und der RCPool für die neue Region übermittelt.
8. Die alten RegionController weisen den Client mit einem NEWREGION Kommando an, dass er sich mit anderen RegionControllern verbinden muß.
9. Die Command-Queue wird geschlossen. Der Client schließt alle offenen Verdingungen.
10. Der Client startet eine neue Befehls-Warteschlangen über die initCommandQueues()-Methode. Die Warteschlange öffnet Verbindungen zu den neuen RegionControllern.
11. Nun ruft der Client abschließend die startGame()-Methode auf und nimmt den regulären Spielbetrieb wieder auf
12. Der Client spielt weiter

5.4.5 Logout

In der Grafik 5.3 sind folgende Schritte skizziert:

1. Der Client erzeugt ein MmpgP2PCommand vom Typ LOGOUT. Dieser wird an die RCs übertragen.
2. Die RegionController des RC-Pools deaktivieren den Client sofort. Er erhält keine Updates mehr und seine Spielzüge werden sofort verworfen.
3. Die RCs öffnen eine Verbindung zum Server
4. Die RCs übertragen die Avatare des Clients zum Server und dieser speichert sie persistent
5. Die RCs teilen dem Server mit, dass sich der Client ausloggt
6. Der Server deaktiviert den Client und löscht die Zuordnung zu seinem RC-Pool
7. Der Server bestätigt den Vorgang
8. Die RCs übertragen ein MmpgP2PCommand vom Typ CLOSE an den Client
9. Die Command-Queue wird geschlossen. Der Client schließt alle offenen Verdingungen.

5.4.6 Splitting einer Region

Im Abschnitt 4.3.4 wurden diese Punkte bereits angedeutet.

In der Grafik 5.4 sind folgende Schritte skizziert:

1. Der RC-Pool signalisiert dem Server, dass er seine Region splitten möchte. Gleichzeitig wird ein Vorschlag übermittelt, wo die Grenze des Splittings verlaufen sollte. ^5.2
2. Der Server sucht freie RegionController (siehe 4.2.3) für den neuen RC-Pool. Die Anzahl an RCs im Pool wird durch Parameter gesteuert.
3. An jeden dieser RCs schickt er einen MmpgP2PCommand vom Typ PREPARE mit entsprechenden Parametern, um die Übermittlung der neuen Region vorzubereiten.
4. Nun übermittelt der Server den eigentlichen SPLIT Befehl an die RCs. Der neu erzeugte RC-Pool B wird ebenfalls als Parameter übertragen, damit die RCs des alten RC-Pool A wissen, wohin sie die neue Region übertragen müssen. ^5.3
5. Das Spiel wird in dieser Region für die Zeit des Splittings pausiert.
6. Die RCs des ``alten'' RC-Pools A führen das Splitting der Region durch.
7. RC-Pool A kontaktiert RC-Pool B und übermittelt die neue Region in Form einer GameWorld Klasse. Die GameWorld Klasse enthält auch alle Objekte innerhalb dieses Teiles der Region.
8. Nun werden noch die Avatare an RC-Pool B übertragen.
9. Das Splitting ist durchgeführt und kann dem Server bestätigt werden.
10. Der Server aktualisiert seinen RegionTree (siehe 4.1.2.1) mit den neuen Daten.
11. Die Clients, deren Avatare sich innerhalb der neu entstandenen Region befinden, bekommen einen MmpgP2PCommand vom Typ NEWREGION und verbinden sich mit dem neuen RC-Pool B.
12. Der RC-Pool B informiert den Server darüber, dass sich ein Client nun innerhalb seiner Region befindet (UPDATE Client). Der Server bestätigt.
13. Die Clients erhalten den PLAY Befehl und können nun weiterspielen.

Es sei an dieser Stelle angemerkt, dass der Server vor dem Befehl zum Splitting noch diverse Prüfungen auf Plausibilität durchführt oder das Splitting ablehnt, falls es unsinnig erscheint. Diese Details würden jedoch den Rahmen sprengen.

5.4.7 Serververbindungen

Wird eine neue Verbindung zum Server aufgebaut, dann nimmt der ConnectionListener des Servers diese Verbindung an und startet einen ConnectionWorkerThread. Dieser ist ab sofort für die weitere Verarbeitung ein und ausgehender Daten verantwortlich.

Der erste Befehl während einer neuen Verbindung ist ein String, der den Typ der gewünschten Verbindung spezifiziert. Erkennt der Server z.B. eine HTTP-Verbindung, dann wird ein entsprechendes Interface gestartet. Bei eingehenden Client- oder RC-Verbindungen wird ebenfalls ein entsprechendes Interface gestartet.

Die Verbindungen bleiben so lange offen, bis ein konfigurierbarer Timeout auftritt, oder bis das System die Verbindung manuell trennt (z.B. direkt nach der Verarbeitung eines HTTP-Requests).

5.5 Beschreibung wichtiger Klassen

5.5.1 MmpgP2PCommand

Ein Kommando kann man folgendermaßen erzeugen:

int         id = 1000000;
Object [] args = { "Parameter 1", "Parameter 2", "Parameter 3" };
MmpgP2PCommand command = new MmpgP2PCommand (id, args);

Unter den Beispielen befindet sich ein Programm namens SendCommand (siehe 6.1.2), das dieses Prinzip verdeutlichen sollte.

Das Kommando mit der ID 0 ist ein sogenanntes No-Operation (NOP)-Kommando. Dieses wird nicht verarbeitet und beeinflußt somit das System nicht. In diesem Fall ist die Argument-Liste null. Ein NOP-Kommando kann durch command = new MmpgP2PCommand() erzeugt werden und dient dazu, dem Gegenüber zu vermitteln, dass trotz Fehlen von übertragenen Kommandos die Verbindung noch besteht.

Welche Kommandos das Spiel verwendet und interpretiert ist Sache der Implementierung. Die vom MMPGP2P-System bereitgestellten Kommandos (ID 1024) dürfen nicht von der Implementierung verwendet oder erzeugt werden.

Benutzerdefinierte Kommandos (ID 1024) werden durch ein Ruleset verarbeitet, das durch den Endanwender implementiert werden muß. Bei der Definition von benutzerdefinierten Kommandos sind keine Einschränkungen vorhanden.

5.5.2 SessionTicket

Das SessionTicket enthält unter anderem eine Sitzungs-ID (sessionID), die im gesamten Netzwerk eindeutig ist und den zugehörigen Client eindeutig identifiziert, und einen Sitzungsschlüssel. Die Verwendung des Sitzungsschlüssels ist optional und kann von der Implementierung für kryptografische Funktionen genutzt werden, um beispielsweise die Gültigkeit eines SessionTickets zu beweisen. Das Framework benutzt diesen Sitzungsschlüssel nicht.

Weiterhin enthält ein SessionTicket eine Liste von RegionControllern in Form einer RCPool-Klasse (siehe 5.3.5). Der Client muss die RegionController dieses RCPools kontaktieren, um am Spielgeschehen teilzunehmen. Die Gültigkeit eines SessionTickets kann zeitlich beschränkt werden, hierfür sind ebenfalls Methoden vorhanden.

5.5.3 MmpgP2PServiceThread

Die implementierenden Unterklassen rufen in ihrem eigenen Konstruktor den Konstruktor MmpgP2PServiceThread(Properties p) auf, damit alle benötigten Einstellungen vorhanden sind, insbesondere Daten zur Verbindung mit dem Server des Systems.

5.5.3.1 Abstrakte Methoden

• log()
  Um das Ausgeben von Informationen oder das Logging von Fehlern zu erleichtern enthält die Klasse abstrakte log()-Methoden. Ein MmpgP2PServiceThread muß diese Methoden implementieren und kann damit steuern, wo Fehlermeldungen landen. Die Beispiel-Implementierung des ClientThread (ClientImplementation) z.B. gibt die log()-Ausgaben in einem grafischen Fenster aus.
• incomingConnection()
  Falls eine Netzwerkverbindung zum MmpgP2PServiceThread aufgebaut wird, dann kommt diese Methode zum Einsatz. In der Regel wird diese Methode von einem ConnectionListenerThread einmal aufgerufen, sobald eine Verbindung eingeht und bevor die Verbindung von einem ConnectionWorkerThread gehalten wird.
• incomingData()
  Jeder MmpgP2PServiceThread muß eingehende Daten verarbeiten können. Dazu dient diese abstrakte Methode, die als Argument einen ConnectionWorkerThread erhält, über den die eingehenden Daten abgerufen werden können. Diese Methode wird in der Regel von einem ConnectionWorkerThread aufgerufen, sobald dieser Daten auf seinem Socket empfängt.
• closedConnection()
  Falls ein noch offener ConnectionWorkerThread beendet wird und seine Verbindung schließt, dann wird diese Methode aufgerufen. Dem implementierenden MmpgP2PServiceThread bleiben dann noch Möglichkeiten, auf die geschlossene Verbindung zu reagieren.

5.5.3.2 Sonstige wichtige Methoden

• getTime()
  Diese Methode ist eine der wichtigsten Funktionen des Systems. Beim Aufbau einer Verbindung mit dem Server wird die lokale Zeit mit der globalen Zeit des MMPG-Netzwerkes abgeglichen und Abweichungen korrigiert. So wird sichergestellt, dass alle beteiligten Peers beim Aufruf der Methode dieselbe Zeit zurückgeliefert bekommen (mit tolerierbaren Abweichungen im Bereich von Millisekunden). Diese Methode löst das in Abschnitt angeschnittene Problem der zeitlichen Asynchronität der beteiligten Peers.
• isStarting() und isRunning()
  Mit diesen Methoden kann man den Status des MmpgP2PServiceThread erfragen.
• stopThread()
  Diese Methode sorgt dafür, dass der MmpgP2PServiceThread sachgemäß beendet wird.
• waitFor(long timeout)
  Wird diese Methode aufgerufen, dann hält der aktuelle Thread so lange an, bis entweder der Timeout (in ms) erreicht wird oder bis der MmpgP2PServiceThread seinen Status auf running gewechselt hat. Diese Methode ist nützlich, um auf den vollständigen Start eines benötigten Threads zu warten.
• getConnectionWorker() und getServerConnectionWorker()
  Diese beiden Methoden dienen dazu, eine reguläre Verbindung zu einem anderen MmpgP2PServiceThread aufzubauen. Erst wenn die Verbindung sicher steht, kehrt die Methode zurück.

5.5.4 ConnectionListenerThread

Wird eine eingehende Verbindung verarbeitet, dann wird die incomingConnection()-Methode des erzeugenden MmpgP2PServiceThread (Parent) aufgerufen. Anschließend wird die Verbindung durch einen neu erzeugten ConnectionWorkerThread (siehe 5.5.5) gehalten. Danach kehrt der ConnectionListenerThread zurück zum Lauschen auf seinen Port.

Diese Thread-Klasse wird beim Server und RegionController verwendet, um viele eingehende Verbindungen anzunehmen und offen zu halten, ohne den eigentlichen Verarbeitungsprozess zu blockieren. ^5.4

5.5.5 ConnectionWorkerThread

Nach einer gewissen Zeit von Inaktivität wird die Verbindung zum Client geschlossen. Es ist also wichtig, dass Clients regelmässig Daten liefern, um die Verbindung aufrecht zu erhalten. Zu diesem Zweck gibt es sogenannte NOP-Kommandos (siehe 5.5.1), die keine Wirkung auf das System oder die Spielewelt haben.

5.5.6 RegionControllerThread

Da die Klasse RegionControllerThread unabhängig von der Klasse ClientThread implementiert wird, ist es möglich, mehrere RegionControllerThreads auf ein und demselben System zu starten. Der Betreiber kann Computer bereitstellt, die RegionControllerThreads (aber keine ClientThreads) starten (vgl. Seti@Home ), und so Flachenhälsen vorzubeugen (siehe 4.2.4).

5.5.6.1 Funktionsweise

Beim Initialisieren eines neuen Spieles übernimmt der initiale RegionControllerThread des Servers die ersten Instanzen von RCThreads. Folgen dann mit der Zeit genügend Clients mit erreichbaren RegionControllern, werden Bereiche der Welt an diese deligiert. Die initialen Instanzen auf dem Server sind ``trusted'', d.h. sie benötigen keine kontrollierenden Instanzen.

Zur Initialisierung bekommt der neue Regioncontroller die benötigten Daten der Spielewelt übermittelt. Sobald der Transfer abgeschlossen ist, müssen die Clients, welche am übertragenen Teil der Spielewelt Interesse bekunden, den/die neunen Regioncontroller abonnieren.

5.5.6.2 Interner Aufbau

Jeder RegionControllerThread sollte grundlegende Informationen über die benachbarten Regionen besitzen. Da die Spielewelt nicht homogen aufgeteilt ist, weiß man jedoch nicht im Voraus, zu welcher Region eine Kachel ausserhalb der Region gehört.

5.5.6.3 Hauptschleife und Ticks

Hat er beides erhalten, dann führt er sogenannte Ticks aus . Ein Tick führt periodisch Aktionen durch. Wie lange das Intervall zwischen zwei Ticks ist, kann die Implementierung durch Setzen eines Wertes im Ruleset bestimmen. Standardmäßig wird alle 200ms ein Tick ausgeführt. Was während eines Ticks geschieht wird ebenfalls im Ruleset definiert, indem der Endanwender diverse abstrakte Methoden implementiert (siehe Abschnitt 5.3.1).

Der RegionControllerThread kann durchaus seine Hauptschleife ausführen, ohne dass ein Client verbunden wäre. Dies kann vorkommen, falls der letzte Client die Region verlassen hat oder falls der RegionControllerThread ``initial'' ist, das heißt er wurde vom ServerThread gestartet und wartet nun auf die ersten Clients. Die Kommunikation mit den Clients wird im folgenden Abschnitt behandelt.

5.5.6.4 Kommunikation mit Clients

Sobald der erste Client verbunden ist, wird der RegionControllerThread in jedem Tick die Änderungen an den Objekten der Welt übertragen. Er führt folgende Schritte aus:

1. tickWorld() auf Ruleset ausführen, Spielewelt updaten
2. Änderungen der Objekte und Avatare in Sichtweite übertragen
3. Falls ein Objekt die Welt verlässt, dieses an den zuständigen RC übertragen
4. Warten, bis der nächste Tick fällig ist

Falls der RegionControllerThread durch Überlastung es regelmäßig nicht schafft, alle diese Aktionen innerhalb eines Ticks auszuführen, dann sollte er gesplittet werden. Bei meinen durchgeführten Tests war der schwache Upstream meines DSL-Zugangs des Öfteren dafür verantwortlich, dass ein Tick nicht in der vorgegeben Zeit abgeschlossen wurde.

5.5.6.5 GZIP-Komprimierung

Bei einer Messung wurden bei vier verbundenen Clients durchschnitlich ca. 50KB/S übertragen, nach der Einschaltung der GZIP-Komprimierung waren es noch 24KB/S.

5.5.7 ClientThread

5.5.7.1 Implementierungen

5.5.7.2 Ablauf eines Logins

Zunächst baut der Client eine Verbindung zum Server auf. Er übermittelt dann Benutzernamen und Kernnwort und erhält bei Erfolg vom Server ein SessionTicket, mit dem er die Regioncontrollern abonnieren kann. Der Server überprüft, ob der Spieler einen gültigen Account besitzt und meldet entsprechende Objekte an die Regioncontroller. Die Regioncontroller werden somit informiert, dass sich dieser Client abonnieren will.

Hat der Server die Regioncontroller entsprechend informiert bzw. hat er neue RegionController zugewiesen, dann erzeugt er das Ticket und übermittelt es an den Client. Danach kann der Client die Regioncontrollern abonnieren. Die Verbindung zum Server wird wieder getrennt, um Ressourcen zu sparen. Alle weitere Kommunikation des Clients mit dem System sollte nun über die RegionController laufen. Von diesen Erhält das System regelmäßig Updates der Spielewelt sowie sonstige System-Kommandos. Im Abschnitt 5.5.8 werden die Details dieser Kommunikation erläutert.

5.5.7.3 Senden von benutzerdefinierten Kommandos

5.5.8 RCQueueWorkerThread

Der Client kommuniziert mit dem MMPGP2P-System auschließlich über Methoden, die der RCQueueWorkerThread zur Verfügung stellt. Soll durch die Methode ClientThread.addCommand() (siehe 5.5.7.3) ein Kommando übertragen werden, dann wird dieses Kommando an den RCQueueWorkerThread weitergeleitet. Er kümmert sich dann um den Versand an alle RegionController.

Der ClientThread überprüft auf der anderen Seite regelmäßig, ob der RCQueueWorkerThread neue Befehle oder Updates empfangen hat. Die neuen Befehle können über die Methode getNextCommand() der Reihe nach abgefragt werden.

Dieses abstahierende Vorgehen erleichtert den Austausch der P2P-Technik, die zum Versenden und Empfangen von Kommandos oder Updates verwendet wird. In der aktuellen Version öffnet der RCQueueWorkerThread Netzwerkverbindungen zu jedem RegionController und versendet Kommandos regelmässig an jeden einzelnen. Beim Empfangen von Kommandos werden diese einfach in die Empfangswarteschlange gelegt und können durch die Methode getNextCommand() vom ClientThread abgerufen werden.

5.5.9 ServerThread

Die Klasse ServerThread ist abstrakt. Der Entwickler muß also eine kleine Anzahl von Funktionen implementieren, damit die Kommunikation reibungslos verlaufen kann.

Der Haupt-Thread des Servers startet einen Hintergrundthread, der nach neuen Verbindungen lauscht. Wird eine neue Verbindung aufgebaut, dann akzeptiert er diese und reicht sie an den Hauptthread zurück. Danach wartet er auf die nächste Verbindung.

5.5.9.1 Protokollierung von Server-Statistiken

Mit der Property server.stats.log_file gibt man die Datei an, in welche protokolliert wird. Setzt man den Wert server.stats.append auf 1, dann werden neue Einträge an eine eventuell bestehende Datei angehängt.

Jede Zeile der Datei enthält eine Protokolleintrag. Eine Zeile, die mit # beginnt, ist als Kommentarzeile markiert und sollte vor einer Auswertung entfernt werden. Innerhalb einer Zeile sind verschiedene Werte durch Tabulatoren getrennt. Welche Werte in welcher Spalte auftreten, gibt eine Kommentarzeile zu Beginn an.

Hier ein Beispiel:

#Server start at        Sun Sep 25 19:12:10 CEST 2005    Timestamp:     1127668331027
#time   regions clients freerc  bytes   load
52      1       0       0       0       0.10
1052    1       0       0       0       0.10
[...]
14070   1       0       0       0       0.08
15072   1       1       0       0       0.08
16073   1       2       2       0       0.08
17076   1       4       4       0       0.08
18076   1       6       5       0       0.08
19076   1       8       8       0       0.07

Die Spalten bedeuten der Reihe nach:

1. Spalte enthält die vergangene Zeit seit dem Start des Servers.
2. Anzahl der Regionen im RegionTree
3. Verbundene Clients
4. Freie RegionController
5. Anzahl an übertragenen Bytes (reserviertes Feld, zur Zeit 0)
6. Load des Servers. Dieser Wert wird unter Linux aus der Datei /proc/loadavg gelesen.

Das Logfile lässt sich leicht mit gängigen Unix-Tools auswerten. Gängige Tabellenkalkulationen können die Datei als CSV-Datei einlesen, indem man das Feldtrennzeichen auf Tabulator einstellt.

5.6 HTTP-Schnittstelle

Figure 5.6: Die HTTP-Oberfläche des Servers

5.6.1 Login über HTTP

Beim ersten Verbinden wird eine Authentifizierung verlangt. Durch Benutzung einer beliebigen Kombination aus Benutzername und Passwort (z.B: hallo:hallo) gelangt man lediglich in ein Informations-Interface. Authentifiziert man sich mit Benutzername ``admin'' und dem zugehörigen Kennwort ^5.5, dann hat man zusätzliche Möglichkeiten. Achtung: Es sollte unbedingt ein Kennwort konfiguriert werden, bevor das HTTP-Interface aktiviert wird.

Der Server trennt eine HTTP-Verbindung nach jeder Übertragung. Dieses Vorgehen ist aus technischen Gründen notwendig gewesen.

5.6.2 Kommandos

• SPLITX <X>:<Y> bzw. SPLITY <X>:<Y>
  Durch X:Y wird die zu splittende Region eindeutig identifiziert. Bei SPLITX wird entlang der X-Koordinate gesplittet, bei SPLITY entsprechend an der Y-Koordinate.
• MERGE <X>:<Y>
  Die Region, welche den Punkt X:Y enthält, soll gemerged werden. Der RCPool der Region wird danach frei.
• SHOWPROPS
  Die Properties des Servers ausgeben.
• RCINFO
  Eine Liste der freien RegionController, eine Übersicht über den RegionTree sowie Details zum initialen RegionController ausgeben.
• CLIENTINFO <ID>
  Informationen zum Client mit der angegebenen ID ausgeben.
• RESETSYSTEMSTATS
  Die SystemStats zurücksetzen, ein neues Protokoll beginnen. Zu weiteren Informatione über die Statistikfunktionen siehe Abschnitt .

---

Next: 6. Verwendung des Frameworks Up: MMPG-P2P Previous: 4. Das Framework ``MMPGP2P''   Contents   Index