eMail
 Suche
 Impressum

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.

3.1 Publisher-Subscriber Modelle

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.

3.1.1 SimMud

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.

3.1.2 Mercury

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 $100 < x < 200$ und $400 < y < 500$. 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 $n$ Nodes durchschnittliche $n/2$ 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.

3.2 P2P-Hybrid: FreeMMG

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.

3.2.1 Funktionsweise

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.

3.2.2 Performanzanalyse des Spiels ``Wizards''

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/
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



- Impressum -
designed using WebCut - Copyright (c) 2001-2008 by Markus Sinner