Peer 2 Peer CA Netzwerk in MMORPG's

Gruppe:

  • Michael Andraschek
  • Stephan Gensch
  • Matthias Schulz
  • Joerg Zinke

siehe auch: Moncore Homepage

Dokumente: Ausarbeitung

Abstract:
1. Definition Netzwerkstrategien
1.1 Definition Client-Server Systeme

Server
Ein Server ist ein Programm, welches auf die Kontaktaufnahme eines Client-Programmes wartet und nach Kontaktaufnahme mit diesem Nachrichten austauscht. Umgangssprachlich wird auch ein Computer, auf welchem ein Server läuft, als ein solcher bezeichnet.(1)

Client
Ein Client (engl. für "Kunde") ist eine Anwendung, die in einem Netzwerk den Dienst eines Servers in Anspruch nimmt. Man spricht dann vom Client-Server-Prinzip.(1)

Client-Server Prinzip
Ein Client-Server-System besteht aus einem Client, der eine Verbindung mit einem Server aufbaut. Der Client bietet die Benutzeroberfläche oder die Benutzerschnittstelle der Anwendung an. Der Server stellt die Funktionalität zur Verfügung.(1)

Die meisten MMORPGs setzen auf dem Client Server Prinzip auf. Die gesamte Spielwelt befindet sich auf einem Server, bzw. auf einer Serverfarm. Der Client bietet eine graphische oder andere Oberfläche um Aktionen auf dem Server auszulösen, die Schnittstelle zum Server.Der Spieler verbindet sich mit Hilfe des Clients zu einem Server und führt seine Aktionen direkt dort aus. Das heisst, wenn der Client Aktionen vornimmt, werden diese an den Server gesendet, dort wird geprüft ob diese Aktionen zur Zeit möglich sind, z.B. kann Spieler in Richtung x laufen ohne an Hindernissen hängen zu bleiben, oder der Spieler bewegt er sich in einen bestimmten Bereich, in dem eine Aktion vom Server ausgelöst werden muss (Angriffsradius eines Monsters). Dieses wird vom Server ausgewertet und das Ergebnis wieder an den Client geschickt, welcher die Aufgabe hat, die entsprechende 3D Welt mit der nun veränderten Situation darzustellen.

Mehrere Clients verbinden sich dabei immer auf einen Server oder eine Serverfarm und spielen zusammen in einer Welt. Dabei gibt es eine Grenze der in der Welt "lebenden" Clients um Serverüberlastung zu verhindern. Jeder Spieler hat über das Netz eine direkte Verbindung zum Server, die Kommunikation geht also nicht über Umwege und es sollte ein flüssiges Spielen möglich sein.

Vorteil dieser Architektur ist, das Clients die Spielwelt nur durch ihr Handeln verändern können, da sie sonst auf die Server keinen Zugriff haben. Würde die Welt auf den Clients liegen, gebe es sicher findige Bastler, welche das zu ihrem Vorteil ausnutzen würden. Sicherlich gibt es Wege und Möglichkeiten auch auf dem Server zu manipulieren z.B. durch Aktionen des Clients welche ebenfalls manipuliert worden sind, bzw durch Skripte oder ähnliches. Jeder Client hat eine direkte Verbindung zum Server und damit der Spielwelt, was ein flüssiges Spielen ermöglichen sollte, es sei denn einer der weiter unten genannten Punkte tritt auf.

Nachteil des Client Server Prinzips ist die evtl. zu hohe Auslastung. Falls zu viele Spieler verbunden sind, oder eine zu grosse physische Strecke zwischen Client und Server besteht kann es vorkommen, das der Server überlastet ist und deshalb nicht schnell genug Rechnen oder auf Clientanfragen antworten kann, bzw. das die Datenpakete zu umständlich geroutet werden und deswegen auch kein flüssiges Spielen möglich ist. Ist der Server mal nicht erreichbar (Updates werden eingespielt, Ausfall wichtiger Hardware rund um den Server, Serverausfall) ist es nicht mehr möglich zu spielen. Da die Charaktere meisstens auch serverseitig gespeichert werden um Manipulation vorzubeugen, ist es dem Spieler also nicht möglich mit seinem Charakter auf einem anderen Server weiterzuspielen (Vorraussetzung ist natürlich es gibt noch andere Server des entsprechenden Spiels).

(1) aus Wikipedia

1.2 Definition P2P Systeme

Peer-to-Peer (engl. peer "Gleichgestellter", "Ebenbürtiger" oder "Altersgenosse/in") ist eine verbreitete Lesart für P2P und bezeichnet Kommunikation unter Gleichen. Andere Interpretationen von P2P lauten Person-to-Person (Betonung der rechnergestützten zwischenmenschlichen Kommunikation) und Program-to-Program (Kommunikation zwischen "intelligenten" Agenten).

In einem Peer-to-Peer-Netz sind alle Computer gleichberechtigt und können sowohl Dienste in Anspruch nehmen als auch Dienste zur Verfügung stellen. Die Computer können als Arbeitsstationen genutzt werden, aber auch Aufgaben im Netz anbieten.(1)

Nutzt man ein p2p Netz füe ein MMORPG so besteht jeder teilnehmende Rechner aus einem Server und einem Client. Jeder Rechner enthält also die komplette Spielwelt oder zumindest Teile von dieser und die Nutzerschnittstelle zu dieser Spielwelt. Einen ersten Ansatz für eine solches Spiel stellt Solipsis, "A peer-to-peer system for a massively multi-participant virtual world" dar - man kann es zwar noch nicht Spiel nennen, aber es treffen die Eigenschaften eines P2P-Systems zu. Eventuell gibt es weitere kleine, von einigen Usern programmierte MORPGs (das erste M soll fehlen), welche aber sehr wahrscheinlich nicht mit Szenegrössen wie WoW zu vergleichen sind.

Bei einer Implementation eines P2P Spieles sind sehr viele Sachen zu beachten. Wie wird die Kommunikation gelöst, es müssen schliesslich bei jeder Spielerbewegung diese Datenpakete auf alle Server verteilt werden. Das führt zu einem grossen Aufkommen an Daten und auch muss jeder Server ständig die Spielwelt aktualisieren. Um noch genügend Rechnezeit für den Client zur Verfügung zu stellen, bedarf es schon einem einigermaßen leistungsfähigem Rechner.

Als zweites ist es hier viel einfacher zu manipulieren. Wenn der Spieler die digitale Welt direkt auf dem eigenen Rechner zu Hause hat, kann er leichter durch Scripte, Hacks oder was auch immer Daten verändern oder hinzufügen. Hier müssen geeignete Schutzmassnahmen gefunden werden.

Als nächstes wäre zu überlegen, ob es sinnvoll wäre, die Spielewelt auf den Servern aufzuteilen. Stellt man sich das Areal des Spieles als quadrat vor, könnte man dieses Quadrat in viele kleine zerlegen. Befinden sich 200 von 290 Spielern alle in einem Viertel der Welt, wird auch nur dieser Abschnitt von deren Servern gerechnet. Die anderen 90 Rechner sind dann für das restliche Dreiviertel zuständig. Hier ist zu überlegen, wie es dann gelöst werden kann wenn ein Spieler ein anderes viertel betritt, für welches sein Server keine aktuellen Daten bereitstellt. Hielt er sich lange dort nicht auf, wird es einiges zu aktualisieren geben, was sich wieder in einer grossen Datenmenge niederschlägt.

So gibt es noch einige andere Punkte welcher im Vergleich zum Client-Server Model schwieriger zu lösen sind.


Anwendungsgebiete von P2P

* Data-Sharing
* Storage
* Distributed Computation
* Collaboration
* Infrastructure Systems

Im Falle von MMORPG ist ein Einsatz von P2P in den Gebieten Distributed Computation (gemeinsame Berechnung der Spielwelt anhand verteilter gemeinsamer Informationen durch Peers), Collaboration (Lokalisieren von Peers und Ressourcen, Suchanfragen) und Infrastructure Systems (Hinzufügen, Entfernen von Clients, Super-Peer-Struktur).


1.3 Definition P2P-CA Systeme

Definition "Peer2Peer" mit Central Arbiter ("CA") Architektur

Joseph D. Pellegrino und Constantinos Dovrolis sagen dazu in "Bandwidth requirement and state consistency in three multiplayer game architectures":

"A game architecture with the scalability properties of the PP model, but also with the simple consistency resolution mechanism of the CS model, would be desirable. To that end, we propose a modified version of the PP model which we call Peer-to-Peer with Central Arbiter model (PP-CA).

In PP-CA, players exchange updates communicating directly with each other, just as in the PP model. This minimizes the communication delays between players. Each player sends its updates not only to all other players, but also to the central arbiter. The role of the central arbiter is to listen to all player updates, simulate the global state of the game, and detect inconsistencies. In the absence of inconsistencies, the central arbiter remains silent, without sending any messages to the players. When an inconsistency is detected however, the central arbiter will resolve it, create a corrected update, and transmit that update to all players. The corrected players should then rollback to the previous accepted state.

The consistency resolution protocol in PP-CA is basically the same with that in the CS architecture. The key difference between the CS server and the PP-CA arbiter is that the former sends a global state update to each of the N players in every player update period, while the latter sends a corrected update to each of the N players only when an inconsistency occurs. If inconsistencies are rare events, the bandwidth requirement at the PP-CA arbiter will be significantly lower than the bandwidth requirement at the CS server."


Zusammenfassung:
In der Architektur P2P-CA tauschen Spieler weiterhin Updates in "Peer-2-Peer-Manier" aus, allerdings ohne Konsistenzüberprüfungen duchzuführen. Konsistenzüberprüfungen erfolgen durch den central arbiter, welcher alle Updates erhält aber nur Spieler kontaktiert, wenn er eine Inknonsistenz entdeckt. Als Ergebnis darraus benötigt der central arbiter weniger Bandbreite als ein Server bei einer Client Server Architektur.

2. Details zum Client Server Ansatz
2.1 Allgemeine Probleme von Client Server Systemen

Der Server bei Client Server Systemen stellt einen sogenannten "Single-Point-of-Failure" (SPoF) dar, wenn der Server ausfällt kann keiner mehr spielen. Selbst mehrere Server schaffen hier nicht wirklich Abhilfe, da die Synchronistaion mit Master Server gegeben sein muss. Wenig Bandbreite beim Client hat unter Umständen (abhängig von Komplexität des Spiels und Anzahl der Spieler) immense Bandbreite beim Server zur Folge. Hohe Latenzzeiten sind das nächste Problem mit dem Client Server System zu kämpfen haben. Desweiteren skalieren sie nur sehr schlecht und wenn man dann noch Live-Backups vom Server machen möchte ist jegliche gute Konnektivität dahin und somit auch der Spielspass hinüber.

Ein weiteres Problem ist die begrenzte Rechenkapazität des Servers. Die Spielwelt muss so gestaltet und dimensioniert sein, das diese auch noch problemlos vom Server verwaltet und berechnet werden kann. Werden dafür mehrere Server im Verbund genutzt, ist hier wieder eine Netzwerstruktur von Nöten, welche, neben den Rechnern an sich, auch einen Kostenfaktor bildet.

2.2 Traffic Probleme bei Client Server Systemen

Client Server Systeme sind zwar weit verbreitet jedoch auch vom Konzept/Ansatz her hoffnungslos veraltet. Sie sind nicht mehr zeitgemäss, wie die Beispiele Korea und Lineage als 2 Millionen Spieler weltweit) zeigen: es gibt immer mehr Breitbandanschlüsse und immer mehr Spieler...

Es können zwar durch Optimierungen der Paket-/Fragment-Grössen noch einige Ressourcen freigeschaufelt werden - langfristig wird das jedoch nicht reichen. Ein ganz anderer Optimierungsansatz: mal ein neues Protokoll. Zum Beispiel auf UDP-Basis, um den Verbindungsauf- und Abbau-Overhead von TCP einzusparen.

Mit einem Modem ist bei Online-Games ja sowieso schon lange kein Blumentopf mehr zu holen (aus http://wow.stratics.com/content/features/editorials/mech/ ):

"Will the modem users be ok with that? If we assume the calculated minimum of 75 bytes per packet, a modem user could theoretically have enough bandwidth to receive the movement of almost 100 players per second. But there's another aspect: multiple movements can be grouped in a single packet, so that we don't have to bear the overhead of 50 bytes for each movement. If we group 10 movements in a single packet, we would come up with 10 packets of around 300 bytes each, summing up to a total of 3000 bytes or 24000 bits (if you didn't know already, 1 byte = 8 bits), which is less than half the bandwidth of a 56kbps modem. However, all these calculations have been based on a 'best case'. What happens when the users start casting spells and fighting? There's a lot more data to be sent... Seeing that Blizzard is telling us that the typical raid will be 30 people, on a 56kbps modem, we would have about 200 bytes/sec for each player, up to a maximum of 230 or so."

Ergo neue Technologien müssen her: P2P


3. Details zum P2P Ansatz
3.1 Vorteile und Nachteile von P2P

Vorteile von P2P
* Lastverteilung
* dezentralisiert
* skalierbar
* weniger Latenz als bei Client Server Systemen
* fehlertolerant bei Absturz eines Servers = Peers = Clients
* dynamisches Erweitern oder Entfernen eines Knotens ohne Beeinträchtigung der Leistung des Netzwerkes
* Aufteilung der Welt auf Peers möglich
* Bandbreite verteilt sich (auf Peers)
* Speicherkapazität

Nachteile von P2P
* höhere Bandbreite (insbesondere bei den Peers) erforderlich (Peers*Aktion Nachrichten oder Aktion*Nachbarn Nachrichten) durch allgemein hohes Datenaufkommen
* Findung der Nachbarn bei Neueinstieg
* schwieriger zu warten (Inkonsistenzen)
* Gefahr modifizierter Peersoftware ohne zentrale Kontrollinstanz
* Implementation von Statistikserver schwieriger, da keine zentrale Sammelstelle
* mangelnde Authentizität

3.2 P2P-CA

* kombiniert Vorteile aus P2P- und Client Server Systemen
* Bandbreite verteilt sich besser
* Inkonsistenzprobleme werden durch den CA (central arbiter) behoben

3.3 Verwaltung eines P2P-CA

* Konzepte zur Konsistenzerhaltung
* Gruppenkommunikation: Broadcast- und/oder Multicastkonzepte

4. Sicherheit
4.1 Schaffen einer sicheren Netzwerkstruktur

Einleitung
Dieser Abschnitt soll erläutern, welche Aspekte der Sicherheit für ein MMORPG von Bedeutung sind.

Sicherheitseigenschaften
Sicherheitseigenschaften geben an, unter welchen Voraussetzungen Systeme als sicher angesehen werden können.

  • Funktionssicherheit ist die Eigenschaft, dass die realisierte Funktionalität eines Systems mit der spezifizierten Funktionalität übereinstimmt. Jede Systemkomponente (Super-Peer, Server, Client) verhält sich ausschliesslich nach ihrer spezifizierten Rolle.

  • Informationssicherheit teilt sich in zwei Aspekte - der Sicherung der Informationen innerhalb eines Rechnersystems und der Sicherung der Information während der Übertragung. Innerhalb eines Rechnersystems dürfen Server und Client nur Zustände annehmen, die zu keiner unauthorisierten Informationsveränderung oder -gewinnung führen. Zugriffe auf Spielweltdaten dürfen nur über den Server erfolgen, ein Client stellt nur Anfragen und erhält das Ergebnis vom Server zurück. Werden Spielweltdaten auf Peerseite gehalten, dürfen diese nicht durch Skripte o.ä. manipulierbar sein. Zum erkennen von Angriffen auf die Informationssicherheit empfiehlt sich der Einsatz von Monitoring und Intrusion Detection Tools. Während der Übertragung von Daten zwischen Client und Server oder Peers dürfen diese nicht verändert, abgefangen, oder in anderer Weise manipuliert werden. Es muss eindeutig sein, wer Sender und Empfänger sind, und die Daten sollten garantiert ihr Ziel erreichen. Sofern es der Spielperformanz keinen Abbruch tut, sollte die Übertragung verschlüsselt erfolgen (SSL, PGP), evtl. zusätzlich mit Prüfsummen versehen (MD5, SHA-1).

  • Datenschutz: Daten von Spielern - sowohl real- als auch virtual-life - dürfen nicht von unauthorisierten Personen gelesen, verändert oder gelöscht werden. Dies ist insbesondere für kommerziele MMORPG entscheidend, wo sicheres Accounting entscheidend ist.

  • Verbindlichkeit ist, wenn eine Aktion eines Spielers später nicht mehr abgestritten werden kann, d.h. alle Aktionen die in einer Spielwelt ausgeführt werden, sind auch tatsächlich geplant gewesen (bzw. von einem Client ausgeführt worden - beinhaltet auch Fehler eines Spielers).

  • Verfügbarkeit bedeutet, dass ein Anwender keinerlei Einschränkungen hinsichtlich der ihm erlaubten Benutzbarkeit des Systems erfährt. Die Spielweltberechnenden Instanzen (Server, Server-Farm) müssen ständig erreichbar sein, ebenso evtl. Authentifizierungs- und Datenserver. Sie müssen gegen D.o.S. Angriffe bestmöglichst geschützt werden, beispielsweise durch entsprechende Gateways, die keinen direkten Zugriff auf Server erlauben, sondern diesen maskieren. Ein weiterer Aspekt der Verfügbarkeit ist, dass das System ausreichend skaliert, d.h. die Spielweltberechnung und Verteilung der Daten unabhängig von der Spieleranzahl performant abläuft (bis zu einer gewissen Spieleranzahl).

Grundsätzlich sollte man nicht davon ausgehen, dass die benutzte Verschlüsselung oder Protokolle vor den Spielern sicher sind. Alle Daten, die von Spielern gesendet werden, müssen von der zentralen Instanz (Server o. Super-Peers im P2P-CA) auf Gültigkeit geprüft werden. Häufig werden bei Servern feste Puffer für eingehende Daten an Sockets verwendet, was Angriffsfläche für Buffer-Overflow-Attacks bietet, falls eingehende Pakete nicht überprüft werden. Ebenso müssen Anfragen inhaltlich auf ihre Korrektheit und Ausführbarkeit geprüft werden, um zu verhindern, dass beispielsweise Spieler Gegenstände benutzen, die nicht in ihrem Besitz sind, Handel mit Spielern treiben, die weit entfernt sind, oder Zugang zu Bereichen erhalten, für die sie noch nicht zugelassen sind, etc. Wann immer Verletzungen der Sicherheit auftreten, sollten diese mit relevanten Zusatzdaten geloggt werden. So lassen sich zum Beispiel nicht nur gezielte Angriffe, sondern auch Fehler erkennen, falls ein Sicherheitsproblem nicht nur von einem oder einigen wenigen, sondern von vielen Clients verursacht wird. Umgekehrt, sollten mehrere Sicherheitsverletzungen von nur einer Quelle kommen, kann davon ausgegangen werden, dass Versuche unternommen werden, die Integrität des Netzwerks zu stören.

Gleichzeitig sollte die Menge an Daten, die an Clients gesendet wird, beschränkt werden, um zu verhindern, dass diese eine globale Sicht auf das Spiel erhalten. Nur für sie relevante Daten, wie Spieler in näherer Umgebung, Objekte o.ä. sollten Clients zur Verfügung stehen. So sollte auch die Information, wo sich Spieler befinden, zentral gehalten werden und nicht auf Clientseite. Clients reichen lediglich Bewegungsanfragen weiter, gehen diese über zulässige Werte, werden sie serverseitig verworfen. Dadurch können z.B. Handelsanfragen zwischen zu weit entfernten unterbunden werden.

Voraussetzungen/Fragen
Welche Daten werden an welchen Orten gehalten und wer darf sie modifizieren?
Welche Protokolle sind für die Datenübertragung zu benutzen?
Wie kann unbefugter Zugriff auf das Netzwerk verhindert werden?

4.2 Maßnahmen zur Erhaltung der Netzwerkstruktur

Registrierte Spieler müssen tun können, was immer ihnen, abhängig von ihrem Kontext, erlaubt ist. Jegliche andere Aktionen sind auszuschließen, d.h. ein Spieler darf niemals in der Lage sein, auf seine oder Daten von anderen Spielern zuzugreifen und zu seinem Vorteil (oder zu anderer Spieler Nachteil) zu modifizieren. Ging es in Netzwerkstruktur vorwiegend um das Erschaffen eines sicheren Netzwerkes nach aussen hin, werden hier die notwendigen internen Konzepte vorgestellt.

5. Praktischer Teil
5.1 Idee



Aufgrund bisheriger Vorbetrachtungen, persönlichen Interessen und der Notwendigkeit, etwas anderes machen zu wollen, als unsere Parallelgruppe, haben wir beschlossen, ein Peer2Peer-System zu implementieren. Dabei werden wir versuchen, vorerst einen Terminalclient/-server/-peer zu basteln, welcher nach Start mit seinen Nachbarn Kontakt aufnimmt, die gemeinsame Datenbasis, die die Welt symbolisieren soll, abgleicht/synchronisiert und so alle Peers auf dem aktuellen Stand ihrer Spielsucht nachgehen können.

Führt ein Peer eine Aktion aus, ist eine Zeitschwelle überquert worden oder soll ein Heartbeat an die Nachbarpeers verschickt werden, werden aufgrund vorherrschender Nachbarschaftsbeziehungen Daten zwischen den Peers ausgetauscht.

Als Entwicklungsplattform kommt dabei Linux und/oder *BSD zum Einsatz. Als Programmiersprache wird Python herhalten dürfen. Aufgrund der Plattformunabhängigkeit von Python wird die Implementierung auch problemlos unter Windows und Mac OS X laufen.

Nach weiteren Überlegungen und Recherchen in der Literatur sind wir zu dem Punkt gekommen das ein reines Peer2Peer-System nicht ausreicht. Es wäre den Anforderungen nicht gewachsen und ständig überlastet. Deswegen implementieren wir ein sogenanntes hybrides Peer2Peer-System auch bekannt als P2P-CA mit einem sogenannten Central Arbiter.

Wir werden uns dabei aber vermutlich nicht konsequent an das P2P-CA Modell halten, sondern es noch etwas erweitern um es besser implementieren zu können. In unserer Implementierung wird der central arbiter mehr eine Art "Super Peer" sein.


5.2 Entwurf

Allgemein

aus http://escience.anu.edu.au/lecture/ivr/architecture/ :

How to set up a Peer to Peer Architecture

  • Chose broadcasting or multicasting...

  •  Chose either some ports number, and IP scope (broadcasting), or some Multicasting IP Number

  • or even TCP and UDP, with a registration server

  •  Let each client take care to send its position/speed... to the subpart of the full network or to the Multicast address

Netzwerkentwurf (P2P-CA)

Die Grafik symbolisiert unseren Entwurf der Netzwerkstruktur. Dabei kommunzieren Peers in einer Wolke untereinander mit zentraler Instanz. In jeder Wolke gibt es eine Art Super-Peer, der das P2P-CA ausmacht. Er ist der central arbiter. Dieser ist auch dafür verantwortlich, sich mit anderen Super-Peers in Verbindung zu setzen und Nachrichten so an nicht in der gleichen Wolke befindlichen Peers zu liefern. Die Super-Peers verschicken dabei Multicastnachrichten, die von anderen Super-Peers geroutet werden müssen (Beispiel Nachrichten 1->2->3->4).


Der Schwerpunkt unseres Entwurfs liegt auf der möglichst Latenzfreien aber doch gesicherten Kommunikation. Das Netzwerk sollte plattformunabhängig und generisch sein. Es ist damit für jeden Typus von Spielen geeignet. Dank der geringen Latenzen bieten sich 3D-Ego-Shooter natürlich an, trotzdem sind auch Kartenspiele möglich, egal ob mit oder ohne Chat-Funktionalität.

Sicherheit
Alle Connections zwischen allen Peers und Super-Peers sind verschlüsselt. Alle Nachrichten sind mit Hashwerten versehen und verhindern dadurch cheating über man-in-the-middle-attacken.

Trotz der Verschlüsselung sollten Latenzen gering bleiben.

Protokollentwurf
Aufgrund des generischen Ansatzes überlassen wir dem eigentlichen Spieleentwickler die Entscheidung, wie das Protokoll für sein Spiel aussehen soll. Wir bieten ihm eine Netzwerk, welches zuverlässige, sichere, plattformunabhängige und hoffentlich weitestgehend latenzfreie Kommunikation bietet. Das darrauf aufbauende Protokoll kann beliebig aussehen um jeden Typus von Spiel unterstützen zu können.

Das heisst auch das Synchronisieren der Welten bei Ego-Shootern zum Beispiel bleibt Sache des Entwicklers. Wir bieten ihm eine Plattform dafür.

Accounting
Bis jetzt ist das Accounting von Clients nicht vorgesehen in der Implementierung.

Schnittstellenentwurf
Die Schnittstelle mit der der Entwickler auf unser Netzwerk zugreifen kann wird vermutlich IPC sein.

5.3 Implementierung

Warum in Python?

  • einfach und modular aufgebaut

  • plattformunabhängig

  •  objektorientiert

  •  alle benötigten Module im Core enthalten, keine zusätzliche Software muss installiert werden

  •  Alternative: Java und das JXTA-Framework

A. Anhang
A.1 Links

3D-Engines, auf denen schon MMORPG erschaffen worden sind:


A.2 Fragen und Aufgaben
Inwieweit sind MMORPG social software?"

2002 benutzte Clay Shirky den Begriff “social software” um jegliche Software, die Gruppeninteraktion unterstützt - sowohl online als auch offline - zu umschreiben. Diese Begriffsfindung geht zurück bis in die 40er Jahre des 20. Jahrhundert und beruht auf der Idee Kommunikation und Gruppeninteraktion mittels datenverarbeitenden Maschinen zu ermöglichen, wobei das besondere Augenmerk der Interaktion von Individuen und dem Erreichen von "Gruppenzielen" galt. Peter and Trudy Johnson-Lenz definierten in den späten 70ern den Begriff Groupware als intentional group processes plus software to support them. Zunächst waren diese Ansätze, z.T. wegen fehlender Technologie theoretischer Art, fanden jedoch später Anwendung insbesondere im Office-Bereich. Andere Begriffe, wie Collaborative Software, Decision Support System, Computer-mediated Kommunication, Collective Intelligence oder Groupware lassen die gedanklichen Ansätze zur Begriffsfindung deutlich werden.

In MMORPG benutzen Spieler Software um mit anderen Spielern zu kommunizieren (verbal (Schrift, Sprache) oder durch Aktionen (Bewegung, Kämpfe, Handel)). Meist sind Optionen vorhanden, mehrere Spieler zu einer Party zu vereinigen, und so als Gruppe gemeinsam mit anderen Spielern oder Gruppen zu interagieren.
Welche Probleme können beim client / server auftreten?


Was für "cheats" existieren in MMORPG?"

Da die Frage sehr allgemein ist, hilft eine Klassifizierung der möglichen Ansatzpunkte, sich einen irregulären Vorteil zu verschaffen.

Zum einen können Konsolenbefehle, die beispielsweise Gesundheit wiederherstellen, oder den Munitionsvorrat auffüllen benutzt werden. Dies ist meistens jedoch recht harmlos und teils von Entwicklern auch beabsichtigt, um Eater Eggs" o.ä. und spezielle Handlungen (z.T. werden Aktionen wie winken, tanzen, Drohgebärden, etc. über Konsolenbefehle realisiert). Hier gilt halt: wer's kennt hat einen Vorteil, Kenntnis darüber zu erlangen ist jedoch prinzipiell nicht schwierig und somit für jedermann anwendbar. In manchen MMOG können Administratoren als Spielerfiguren gesonderte Befehle haben, um beispielsweise Spieler sofort zu töten, oder ähnlich destruktive"" Maßnahmen durchzuführen.

Ein anderer Ansatzpunkt sind Schwachstellen bei der Übertragung von Daten unter den Spielern sein, die, wenn erkannt ausgenutzt und manipuliert werden können - das wäre allerdings kein Cheat im klassischen Sinne und würde spezielle Kenntnisse und einen gewissen (un)sportlichen Ehrgeiz voraussetzen.

Wie wird Skalierbarkeit in MMORPG erreicht?
Skalierbarkeit wird erreicht, in dem auf jedem Server nur ein bestimmte Anzahl Spieler zugelassen werden. Beim klassischen Client Server Model ist es meisst so gelöst, das mehrere Server oder Serververbünde mit exakt der gleichen Spielwelt, den gleichen Aufgaben usw. bereitgestellt werden. Es werden maximale Spieleranzahlen pro Server berechnet bzw. festgelegt, welche dann auch nur tatsächlich auf dem Server zugelassen werden. Die Spieler auf einem Server teilen sich dann ihre Welt, während andere Spieler diese Spieler nich kennen, obwohl sie in der gleichen Welt aber nicht auf dem gleichen Server spielen. Durch solche Maßnahmen kann erreicht werden, dass die Server nicht überlastet werden und so bestmöglich skalieren.

Wie entsteht die Latenz bei MMOG und welche Einflüsse hat sie? welche Protokolle werden eingesetzt?
Die Latenz in MMORPGs entsteht durch den Datenaustausch über den Server. Führt ein Spieler eine Aktion aus, wird diese an den Server gesendet, von diesem auf ihre Durchführbarkeit geprüft (Abhängig von verschiedenen Faktoren) und bei Erfolg an alle Clients gesendet, welche unmittelbar von dieser Aktion beeinflusst werden. Tötet ein Spieler z.B. ein Monster welches sich auch im Sichtbereich anderer Clients befindet, muss diese Monster bei allen anderen Spielern als tot aktualisiert werden. Besitzt der tötende Spieler ein langsame Internetverbindung, welche durch ankommende Daten schon fast ausgelastet ist, so wird es länger dauern bis diese Aktion beim Server eingeht, geprüft ist und dann an andere Clients gesendet wird. So kann es vorkommen das Spieler beim laufen wild in der Gegend rumspringen, da die Akualisierungen nicht rechtzeitig bei anderen Clients ankommen und der Server eine zu weit entfernte neue Position des Läufers angibt, welche dann durch einen Sprung in anderen Clients aktualisiert wird.

Latenz kann auch durch ausgelastete Server entstehen, welche kurzzeitig Aufgrund von zu vielen Anfragen keine neuen bearbeiten können.

Die Einflüsse von Latenzen reichen von minimal bis sehr ärgerlich. Wenn jemand vor mir läuft und springt plötzlich ein Stück nach vorn ist das nicht ärgerlich. Anders sieht es aus, wenn ich mich im Kampf mit einem anderen Mitspieler befinde. Eventuell befindet sich dieser laut Server nicht mehr an der Stelle auf die soeben geschossen wurde, sondern schon woanders und damit treffe ich ihn zwar auf meinem Bildschirm, der Server verweigert diese Aktion aber und berechnet ein nicht getroffen und in meinem Client wird es dann auch so aktualisiert. Andersherum bewege ich mich in einem Kampf, meine Daten werden durch zu hohe Latenz beim Server erst kurze Zeit später verarbeitet, in diesem Moment werde ich laut Server getroffen, obwohl ich schon lange (laut meinem Client) nicht mehr an dieser Stelle war.

Wie können die Serverlast / der Traffic bei MMORPG reduziert werden? Von welchen Faktoren ist die Auslastung abhängig?
Die Serverlast kann reduziert werden, indem mehrere Server sich in einem Verbund die Berechnungen einer Spielwelt teilen. Man kann sie parallel die ganze Welt berechnen lassen, oder aber die Welt auf die Server aufteilen. Für die Aufteilung wäre ein Masterserver von Nutzen, welcher die Aufgabe hat alle ankommenden Nachrichten bzw. Anfragen an die verschiedenen Server weiterzuleiten, je nach dem, aus welchem Sektor der Spielwelt die Anfrage kam. Ein einfaches Routing also. Traffic kann reduziert werden, wenn mehrere Nachrichten in einem Paket verschickt werden. Da die Nachrichten teilweise nicht ross sind und somit nicht vollständig ein Datenpaket ausfüllen, könnte dadurch erreicht werden, das Datenpakete effizienter genutzt werden und es könnten die Header für die anderen Pakete eingespart werden, was eine nicht unwesentliche Reduktion des Traffic ausmachen würde. Ausserdem ist zu beachten, das nicht jeder Client über jede Aktion eines anderen Clients vom Server informiert werden muss. Es reicht wenn er die Informationen erhält, die sich unmittelbar auf die ihm sichtbare Spielwelt beziehen, bzw. in einem bestimmten Umkreis seiner Spielweltansicht alle Aktionen aktualisiert werden.

Wodurch entsteht die Trennung in Shards? (wie) kann diese aufgehoben werden?
Kurze Erklärung warum das eigetnlich Shard heisst: "Im Vorspann des Computerspiels Ultima Online wird beschrieben, wie das Multiversum von Ultima Online entstand. Es wird beschrieben, wie ein mächtiger Avatar den bösen Zauberer Mondain erschlug. Mondain hatte die Welt Britannia (bekannt aus der Singleplayer Serie von Ultima) in einen Kristall gebannt. Nach dem Tode des Zauberers zerschlug der Avatar den Kristall, um die Welt Britannia von der Macht des Kristalls zu befreien. Der Zauber des Kristalls wirkte jedoch immer noch auf die Welt Britannia und diese existierte nun als Kopie in jeder Scherbe (Shard) des Kristalls." aus Wikipedia

Die Trennung in Shards erfolgt aus dem Grund, damit die Serverlast nicht zu hoch wird. Würden alle Spieler welche ein bestimmtes Spiel spielen auf einem Server spielen, wäre der Server hoffnungslos überlastet und ausserdem würden sich die Spieler in der Welt wahrscheinlich nicht mehr bewegen können. Nehmen wir das Beispiel World of Warcraft: Es gibt mehrere hundertausend Spieler allein in den USA und Kanada. Würden diese alle auf dem gleichen Server spielen würden oben beschriebene Problem eintreten. Es entstehen immenz lange Wartezeiten, z.B. um ein bestimmtes Monster zu töten, welches für eine Questerfüllung nötig ist. Da dieses Monster aber nur alle 5 Minuten auftaucht, stehen an dieser Stelle einige Spieler und warten (so geschehen in der World of Warcraft Beta), das kann mitunter sehr frustrierend werden. Ein anderer Grund ist die bessere Wartbarkeit der Server. Da viele Spiele mit mehreren Charakteren auf unterschiedlichen Servern spielen, ist es möglich das Server gewartet bzw. upgedated werden können, während die Spieler sich mit anderen Charakteren auf anderen Servern befinden.

Weiter ist zu beachten das Spieler über die ganze Welt verteilt sind. Ein Europäer, welcher auf einem amerikanischen Server spielt wäre aufgrund seiner zwangsweise höheren Latenz benachteiligt gegenüber den Spieler n, welche direkt in den USA sitzen. Es muss also dafür gesorgt werden, das die Verbindungen zwischen Server und Client nicht zu lang werden.

Ob diese Trennung aufgehoben werden kann kommt auf das Spiel an. Handelt es sich um ein kleines Spiel, welches auf nur einem Server abläuft und auch nicht von vielen Spielern gespielt wird, ist diese Trennung von vorn herein gar nicht nötig. Bei grösseren Spielen jedoch wird es schwer ohne diese Trennung auszukommen. Lösungen wären ein risieges Cluster von Servern, wo es auch zu einem Ausfall einiger Server kommen kann, ohne dass die Spieler davon etwas bemerken. Bei solch einer Lösung sind aber hohe Hardwarekosten zu erwarten. Die zweite Lösung wäre ein p2p Netzwerk, denn pro Client welcher am Spiel beteilig ist steht wiederum auch ein Server zur Verfügung, welcher Rechenleistung mit einbringt. Grundvorraussetzung für ein Aufhebung von Shards wäre aber eine Spielwelt welche gross genug ist mehrere tausend Spieler zu beherbergen, ohne das diese sich gegenseitig ´´auf die Füsse treten´´!

Welche Probleme bringt der Entwurf eines MMORPG auf P2P Basis mit sich?
Im Gegensatz zum Client-Server-Konzept hat in einem P2P-basierenden MMORPG jeder Peer, neben der Darstellung der Spielwelt lokal, auch für die Berechnung der Spielwelt und die Kommunikation, bzw. Weiterleitung von Kommunikationsanfragen Sorge zu tragen.

P2P-Netzwerke sind normalerweise hochgradig dynamisch durch ständig beitretende und das Netzwerk verlassende Teilnehmer. Jedoch ist es notwendig, gewisse statische Strukturen beizubehalten, um eine zentrale Stelle (oder ein zentrales Netzwerk) für die Datenhaltung der Spieler bereitzustellen. Würde dies nicht geschehen, d.h. alle Peers sind gleichberechtigte Teilnehmer, die auch Spieldaten verwalten, könnte den Peers die Möglichkeit gegeben sein, Daten zu manipulieren.

Wie die vorherige Frage anreißt, hat sich im Laufe der Zeit die Notwendigkeit von Shards herauskristallisiert um einen Spielbereich mit ausreichender Qualität und Performanz einer gewissen Menge von Spielern zur Verfügung zu stellen. In einem P2P-Netzwerk läßt sich eine Trennung in verschiedene Bereiche schwierig realisieren, aufgrund der dynamischen Gruppenbeitritte. Es müßte ein Metamodell für eine Bereichsunterteilung eingerichtet werden, welches dynamisch Spielweltberechnungen an Peers verteilt, abhängig davon, in welchem Teil der Spielwelt sie sich befinden. Da dafür jedoch ein erhebliches Nachrichtenaufkommen und Synchronisationsbedarf besteht, ist ein reines P2P-Netzwerk für größere MMORPG zu inperformant.

Gibt es eine Grenze der Gruppengröße, so dass ein ihr angehörendes Individuum zu allen Gruppenmitgliedern stabile Beziehungen unterhält?

Ein Anthropologist des University College of London, Prof. Robin Dunbar, schrieb in Co-Evolution Of Neocortex Size, Group Size And Language In Humans über Dunbar's Nummer: ... there is a cognitive limit to the number of individuals with whom any one person can maintain stable relationships, that this limit is a direct function of relative neocortex size, and that this in turn limits group size ... the limit imposed by neocortical processing capacity is simply on the number of individuals with whom a stable inter-personal relationship can be maintained.

Laut seiner Arbeitsergebnisse liegt die mittlere Gruppengröße für Menschen bei 147.8 , welches Datenerhebungen über Dorf- und Stammgrößen verschiedener Kulturen gleicht.


Was ist das "concurrent server model" ? 
Dieses Prinzip beschreibt kurz gesagt das Prinzip, dass ein Server auf Anfragen von Clients wartet und bei einer solchen Anfrage ein Prozess spawned, der dem Client zugeordnet ist und die Anfragen des Clients bearbeitet. Ist dieser client-zughehörige Prozess erschaffen worden, dann wartet der Server, meist über eine Socket, auf neue Anfragen von neuen Clients. Diese werden dann ebenfalls mit einem für den Client erschaffenen Prozess bedient. Diese client-zugehörigen Prozesse laufen parallel. Terminiert ein Client die Verbindung, wird der Prozess, der den Client bedient hat, beendet. Diese Verbindungen geschehen meist über TCP/IP.

Daraus ergeben sich natürlich Fragen nach der möglichen Grenze solcher parallelen Verbindungen. Wie ist die Ressourcenverteilung unter den einzelnen Prozessen aufgeteilt. Wie verhält sich das System, wenn ein Client eine Ressourcenfressende Anfrage stellt, andere Clients zum gleichen Zeitpunkt keine Last verursachen - wird dem Prozess mit der Arbeit voller Ressourcenzugriff ermöglicht oder bleibt sein Ressourcenreservoir bei Ressourcen/NrOfProcesses beschränkt. Die Implementation dieses Prinzips entscheidet letztendlich über die genaue Semantik bei parallelem Bearbeiten unterschiedlicher Clients.

(1) aus Wikipedia


Zuletzt aktualisiert: 23. November 2005 12:04

Zurück Nach oben Weiter