Subsections
3. Existierende Ansätze und Lösungen
Es existieren bereits Lösungsansätze und Implementierungen, welche verschiedene
Problematiken behandeln, um sich von einer starren Client-Server-Architektur
zu lösen. Im Folgenden sollen einige Arbeiten vorgestellt werden.
Publisher-Subscriber (Pub/Sub) Modelle sind ``Message Oriented Middleware'' Systeme, die
auf P2P-Systemen bauen. Der Erzeuger (Publisher) stellt dem Konsument (Subscriber)
Nachrichten (Messages) zur Verfügung. In der Regel werden Gruppen gebildet, die
einen bestimmten Typ von Nachrichten empfangen bzw. verarbeiten.
Im Gegensatz zu Broadcasting Systemen, wo jede Nachricht an jeden Client ausgeliefert
wird, liefern Pub/Sub-Systeme Nachrichten nur an jene Clients aus, die als Subscriber
gelistet sind, Subscriber und Publisher kennen einander jedoch nicht.
Somit wird das Fluten des Netzwerkes verhindert und die schlechte Skalierbarkeit von Broadcasting-Systemen behoben.
``SimMud'' [12], ``Mercury'' [1] und
``A Communication Architecture for Massively Multiplayer Games'' [9]
sind bekannte Projekte, die sich mit dem Betrieb von MMPGs auf einem Pub/Sub System
beschäftigen.
Alle Modelle beschäftigen sich kaum mit Problemen, die aus Cheating resultieren.
SimMud [12] ist eine einfaches MMPG auf P2P-Basis. Es baut
auf dem P2P-Overlay Pastry [25] auf, welches, wie einige
andere P2P-Overlays, mithilfe sogenannter ``Distributes Hash Tables'' eine
Zuordnung zwischen eindeutigen Objekt-Schlüsseln zu eindeutigen Knoten im
Netzwerk leistet. Die Knoten werden automatisch eingefügt und
wieder entfernt, Störungen werden erkannt und behoben.
Der Zustand der Spielewelt wird mithilfe des Systems SCRIBE [2]
verbreitet. SCRIBE ist eine Multicast-Infrastruktur, baut auf Pastry [25]
auf und wird aufgrund seiner Unterstützung von Gruppenbildung als
Publisher-Subscriber-System verstanden (siehe [4]).
Die Welt wird in geografische Regionen mit einer fixe Größe aufgeteilt,
alle Spieler innerhalb einer Region formen eine Gruppe von Interessenten.
Über ein Pub-Sub-System werden Updates innerhalb dieser Gruppe verteilt.
Interaktionen zwischen Spielern werden durch Direktverbindungen verhandelt.
Für jedes Objekt gibt es einen sogenannten Coordinator, an den andere
Spieler Updates schicken, sofern sie das Objekt manipulieren wollen.
Neben dem Coordinator existieren beliebig viele sogenannte Replicas, welche
immer eine Kopie der Anfragen an den Coordinator erhalten, und somit
bei Ausfall des Koordinators einspringen können.
In einigen Experimenten wurde die Performanz des Systems erprobt. Die
meisten Nachrichten benötigen weniger als sechs Hops und werden daher
laut Author meist in weniger als 200ms ausgeliefert. An Netzwerkbandbreite
wurden durchschnittlich 7.2KB/s und 22.34KB/s spitze gemessen. Die Bandbreite
liegt dabei im Bereich gängiger Breitband-Internetanschlüsse, doch
Latenzen von unter 200ms bei sechs Hops scheinen zu optimistisch gewählt.
Das Thema Cheating wurde als zukünftige Erweiterung des Systems
angeschnitten. Jeder Client ist Coordinator seiner eigenen Spielfigur,
und somit bietet das System an dieser Stelle mannigfaltige
Manipulationsmöglichkeiten. Ebenso wäre es jedem Coordinator
gestattet, seine Objekte beliebig zu manipulieren.
Mercury wurde für den Betrieb von Internet-Multiplayer-Spielen entwickelt und
basiert auf einem inhaltsbasierten Pub/Sub-System. Mit diesem System sollten
die Probleme der Skalierbarkeit angegangen werden, die auf Broadcasting
basierende Architekturen wie MiMaze [13] bisher hatten. Das System
skaliert zwar besser mit der Anzahl an Clients, jedoch sind die Latenzen
ziemlich hoch.
Die Spieler erhalten nur die wirklich benötigten Informationen, nämlich Positions-Updates
innerhalb ihrer Sichtweite. Die Nachrichten (Publications) in Mercury sind
Paare von Attributen und Werten (z.B. die X- und Y-Koordinate der Spielerposition).
Ein Spieler erhält dann eine Nachricht, wenn er die Nachrichten für
seine Position abonniert hat. Zum Beispiel abonniert ein Spieler alle
Nachrichten innerhalb seiner Region in den Grenzen und
. Dann erhält er alle Positions-Updates innerhalb dieser Grenzen.
Mercury teilt die Infrastruktur in Hubs auf, welche aus mehreren Knoten (Nodes) bestehen
und welche für die Veröffentlichung eines bestimmtes Attributes zuständig sind.
Innerhalb eines Hubs werden die Knoten kreisförmig angeordnet, wobei jeder Knoten
für einen bestimmten Teil des Attributes verantwortlich ist. Veröffentlichungen
werden kreisförmig an alle Knoten verteilt, bis der für die Daten zuständige Knoten erreicht
wird. Durch dieses Vorgehen müssen Abonnenten ihre Subscription nur an einen einzigen
Knoten innerhalb des Hubs senden.
Wegen der kreisförmigen Anordnung der Nodes benötigen Nachrichten innerhalb
eines Hubs mit Nodes durchschnittliche Hops. Dies führt zu den bereits
erwähnten hohen Latenzen und ist für Spiele ungeeignet.
Zwar wurde das Routing zwischenzeitlich optimiert, doch sind die Latenzen immernoch ziemlich hoch.
Bei 10.000 Clients ist die durchschnittliche Anzahl an Hops etwa 7. Die
Autoren schätzen die Latenzen mit 20ms pro Hop ziemlich optimistisch ein
und errechnen somit akzeptable Werte. Für internetbasierte Spiele sollten
jedoch Latenzen von 50ms bis 150ms als normal erachtet werden, womit sich
ein um einiges schlechteres Bild einstellt.
Auf die Frage, wie stabil sich Mercury während Ausfällen von Nodes verhält,
wird in der Beschreibung nicht eingegangen. Wie bereits oben erwähnt, geht Mercury nicht
das Problem des Cheatings an.
FreeMMG [24] ist ein Hybrid aus auf P2P und
Client-Server basierenden Techniken. Es wurde 2004 entwickelt und mit
300 Clients auf Performanz und Skalierbarkeit getestet. Die Autoren von FreeMMG [3]
veröffentlichten diverse Dokumente und Performanz-Analysen zu ihrer Arbeit.
Der FreeMMG-Server dient als Einstiegspunkt und übernimmt Authentifizierung,
Session-Tracking und die Verwaltung der ``area of interest'' für Spieler.
Ebenso dient er als zentraler Speicher für Backups der virtuellen Welt, die
Echtzeit-Simulation der Welt jedoch obliegt ihm nicht.
Die virtuelle Welt wird in sogenannte Segmente aufgeteilt und die Simulation
dieser Teile der Welt von den Clients übernommen. Die Zuordnung der Spieler
zu ihren Segmenten wird durch den Server geleistet, der zu jeder Zeit darüber
informiert ist, welche Spieler an welchen Segmenten beteiligt sind.
Ein Spieler darf durchaus auch mit mehreren Segmenten interagieren (diese
Segmente sind die ``area of interest'' des Spielers).
Jedoch ist eine Interaktion von Objekten nur innerhalb eines Segmentes möglich.
Die Objekte können zwischen benachbarten Segmenten bewegt werden.
Alle Teilnehmer eines Segmentes müssen dieselben Spielzüge und Simulationsschritte
durchführen und den Zustand der Welt untereinander konsistent halten (``Replicated Simulation'').
Jedes Segment muß eine Mindestzahl von Teilnehmern haben und durch die zufällige
Zuteilung von Teilnehmern zu jedem Segment soll verhindert werden, dass eine Gruppe
von Cheatern den Spielstand fälschen kann, indem sie gemeinsam in ein leeres Segment
wechselt. Laut den Entwicklern wird durch dieses Vorgehen verhindert, dass Manipulationen
an der Umwelt zum eigenen Vorteil durchgeführt werden können.
Auf Basis des FreeMMG-Systems haben die Entwickler ein Beispiel MMG namens
``Wizards'' implementiert. Dieses Spiel demonstriert die Fähigkeit des Systems,
mit mehreren Avataren bzw. zum Avatar gehörigen Objekten umzugehen. Man spielt
einen Magier, der Monster erschaffen und diese zum Attackieren gegnerischer
Magier oder deren Monster benutzen kann. Die eigenen Monster können sich dabei auch in weiter
entfernte Segmenten bewegen: der Client interagiert dann mit jedem Segment, in
dem sich der Magier oder eines seiner Monster befindet.
Die Entwickler von FreeMMG haben Performanz-Tests mit 300 Clients durchgeführt
und den Kommunikationsaufwand (Traffic) des Servers gemessen. Leider scheint der
Zuwachs an Traffic für eine größere Anzahl an Clients nicht mehr linear zu steigen,
so dass nicht vorausgesehen werden kann, ob das System für typische MMOG mit
mehreren Tausend Spielern skaliert.
Der FreeMMG-Server hält zudem eine Verbindung zu jedem Client offen. Dies könnte
zu weiteren Performanz-Problemen führen, wenn die Anzahl der Clients stark steigt.
http://www.psitronic.de/ti/mmpg/mmpg-peer_to_peer/
|