Client/Server, Netzwerk online Spiele

[odenter]

Mich interessiert wie größere Online-Spiele den Netzwerkverkehr handhaben.

Wenn man z.B. einen eigenen kleinen Webserver schreibt, dann ist es relativ simpel, man horcht auf einem Socket nimmt dort Verbindungen an und erzeugt pro Client einen Thread in dem der entsprechende Client mit Daten versorgt wird. Bei einem Webserver kann man jedoch die Verbindung nach dem Senden der Daten gleich wieder beenden und der Thread beendet sich auch.

Wie läuft das bei einem Spiel wie z.B. WoW?
Die werden bei 10000en von Clients vermutlich nicht pro Client einen Thread, auf dem Server, am laufen haben.
Wie läuft die Kommunikation überhaupt per UDP oder doch TCP?

Oder macht man da eher was ala Windows Nachrichtensystem?
Eine Sende-Queue bekommt z.B. Positionsinfos und sendet diese an alle oder bestimmte Nutzer, in einer anderen Queue werden Dinge abgelegt die geprüft werden müssen und diese legt wieder neue Aufgaben in die Sende-Queue. Dieses Queues könnten dann jeweils in einem Thread laufen.

[Lynxeye]

Ich wüsste nicht, was einen heutzutage noch davon abhalten sollte auf einem modernen Betriebssystem einige tausend Threads anzulegen.

Die Kommunikation bei Spielen läuft normalerweise über UDP. Bestimmt wichtige, jedoch nicht zeitkritische Dinge können allerdings auch über einen TCP Kanal übertragen werden.

[odenter]

Naja theoretisch kann man einige 1000 Threads erzeugen.
Auf die Frage bin ich letztendlich durch diesen Artikel hier http://blogs.msdn.com/oldnewthing/archi ... 44912.aspx gekommen.

Auf meinem System (WinXP 32 Bit) gehen normal 2028 Threads. Auf nem 64 Bit System gibts natürlich auch mehr User-Space-Memory.

EDIT:
Der Link aus dem Blog zu der Doku dieser I/O completion Ports ist veraltet, hier der aktuelle:
http://msdn.microsoft.com/en-us/library ... S.85).aspx

[Lynxeye]

Solche kleinen Helferthreads brauchen keinen großen Stack. Also kann man ihn für diese sehr zurückschrauben, dann kann man noch einige Threads mehr anlegen. Und ein 64Bit BS kann man für einen Server schon fast voraussetzen, wenn auch nicht bei den Clients.

[Lord Delvin]

Jeder Rechner, der mehr als 4GB Speicher hat, wird ein 64bit OS haben. Da dich bei deinem Stack nur die Größe des virtuellen Adressraums interessieren muss, kannst du (erstmal für die tätigkeit) davon ausgehen, dass er unendlich groß ist. Danach musst du dir anschauen, was deine Threads tatsächlich an ram verbrauchen. Das musst du dann aber selbst wissen und da kannst du sicher viel optimieren, indem du möglichst viel in shared memory als const reinlegst.
Die TIDs sollten eigentlich auch unter windows64 mitlerweile unbegrenzt sein und wenn das standardmäßig nicht so ist, dann kann man das sicher leicht ändern.

Generell würd ich dir aber raten, den Code möglichst verständlich und skalierbar zu schreiben, dann kannst du, wenn er gut ankommt einfach mehr Maschinen hinstellen, die das bearbeiten:)
Weil man optimierten code halt nicht warten kann...

Gruß
Timm

[odenter]

Ja, nur so wie ich das verstehe skalieren 1000e von Threads schlecht, da durch Context-Switches etc. zuviel Performance verschenkt wird, zumal ja auch in den Artikel geschrieben wird 1 Thread pro CPU.

Ich habe jetzt auch weniger einen konkreten Fall in dem ich das benutzen wollen würde, mich hat erstmal nur interessiert wie man sowas am besten macht.

Bei Gamasutra gibts nen Artikel, da wird aber vorgeschlagen ganz auf Threads zu verzichten, bei Mehrkerncpus keine wirklich gute Idee, und wenn man nicht weiss wieviele Clients tatsächlich behandelt werden wollen noch schlimmer, da mit zunahme der Clients ja immer mehr Clients warten müssen bis sie denn mal dran sind.

[Tanubi]

Hier dürftest du einige Antworten finden.

Tanubi

[Lord Delvin]

Ja, nur so wie ich das verstehe skalieren 1000e von Threads schlecht, da durch Context-Switches etc. zuviel Performance verschenkt wird, zumal ja auch in den Artikel geschrieben wird 1 Thread pro CPU.

Die kannst du dir im allgemeinen aber nur sparen, wenn du eine n:m Abbildung deines Problems auf Threads hinbekommst und das ist glaub ich zu kompliziert um es zu versuchen...du musst dich dann halt um echt viel scheiß kümmern. (EDIT)Dafür wärs halt viel schneller, weil du natürlich auch noch den Cache viel besse ausnutzen kannst, weil dein stack potentiell immer schon im Cache drin ist, egal was du machst...zumindest wenn deine Threads selbst nicht viel ram brauchen...das is mir aber auch erst später eingefallen.

Und wenn du es schaffst, dass alle Threads, die grad nichts machen können beim Kernelscheduler als "blocked" gelistet werden, dann ist skaliert das ziemlich gut, weil dann der kontextswitch quasi mit deiner internen koordination gleichzusetzen ist...außerdem werden context switches auch eher immer billiger.
Gruß

EDIT: das mit dem ram füllen btw. würd ich in nem 64bit system damit lösen, dass man sich noch so 100+ GB swap dazu holt. Du hast eigentlich immer noch irgendwo 100GB rumfahren, und dein Adressraum machts ja mit. Damit würden dann alle Threads, die grad sowieso mit niemandem reden einfach auf der festplatte rumdümpeln...es sei denn du meinst jetzt du willst mit 10k maschinen gleichzeitig irgendwas kommunizieren, dann ist aber glaub auch die anbindung eher dein problem als der mangel an ram.

[DSG]

Bei einem Gameserver für ein Spiel wie WoW programmiert man nicht eine Server-Applikation für einen Server der mit 10000 Threads alle Clients verarbeitet. Wie Blizzard die Serverarchitektur implementiert hat, kann ich dir leider auch nicht sagen.

Doch je mehr Threads in einem Programm, desto schwieriger ist das Programm zu debuggen, das kenn wohl jeder der schon mal mit Threads programmiert hat. Auch für jeden Client einen Thread ist bei Gameserver nicht üblich. Dies mag für ein Spiel mit max 8 Clients sicher kein Problem sein, doch schon mit 30 oder gar 100 Clients ist dieser Ansatz nicht mehr brauchbar. Vielmehr hat man einen Thread (Networkthread) der mittels select() den Socket auf einkommende Nachrichten überprüft und diese verarbeitet.

Für bestimmte Regionen werden mehrere Prozesse gestartet. Würde es nur einen Prozess geben mit vielen Threads, besteht die Gefahr, dass beim Abstürzen eines Threads der ganze Prozess und somit die ganze Zone abstürzt. Hat man aber mehrere Prozesse für diese Region, stürzt nur dieser Prozess ab der fehlerhaft ist und die anderen bleiben unberührt. Es gibt dann einen Sessioncontroller der die Prozesse verwaltet (herunterfahren oder neu starten).

Die Prozesse und der Sessioncontroller existieren auf mehreren (virtuellen) Servern und bilden somit ganze Serverfarmen. Der Client ist immer nur mit einem bestimmten bereich einer Zone verbunden, macht auch Sinn, da der Client ja nicht wissen muss was 10km um Ihn geschieht.

WoW braucht meines Wissens TCP.

[odenter]

Und die einzelnen Regionen, wie Du sie nanntest, reden dann auch z.B. per TCP miteinander (MPI oder sowas), reden die überhaupt miteinander (Peer-to-Peer) oder eher über den Session-Manager der dann entsprechend weitervermittelt oder weiterleitet?

[DSG]

Es ist eine Frage der Architektur wie die Prozesse miteinander kommunizieren. Ich habe mal ein solches System entwickelt, da waren alle Prozesse mittels Peer2Peer (mit RakNet, ist eine Reliable UDP Library) miteinander verbunden. Falls der Spieler nun an den Rand einer Region angelangt, wird der Spieler auf zwei Server repliziert, damit die Spieler auf Server A und auf Server B den Spieler der sich am Rand befindet immer sehen. Dies ist eine recht knifflige Angelegenheit.

Programmiert man auf Windows kann man COM bzw. DCOM verwenden für die Interprozesskommunikation. Linux kenne ich nicht, aber da gibt’s sicher auch Frameworks damit Prozesse miteinander kommunizieren können.

Es wäre aber auch denkbar dass alles über den Sessioncontroller verwaltet wird, somit kann man die Kommunikation auch überwachen und validieren.

[Lynxeye]

Auch für jeden Client einen Thread ist bei Gameserver nicht üblich. Dies mag für ein Spiel mit max 8 Clients sicher kein Problem sein, doch schon mit 30 oder gar 100 Clients ist dieser Ansatz nicht mehr brauchbar.

Kannst du mir dafür eine sinnvolle Begründung geben? Das es zur Zeit noch nicht üblich ist, ist keine Begründung dafür, das es schlechter ist bzw. in Zukunft nicht der bessere Ansatz sein wird.
Warum soll ein select() schneller sein, als 100 blockierte Threads von denen ab und zu mal ein paar wirklich etwas machen? In meiner Belegarbeit habe ich einen Webserver nur unter Nutzung von Threads geschrieben. Ziel war es unter anderem zu beweißen, das die Meinung, ein um select() aufgebauter Server währe bei modernen Maschinen immer noch schneller als einige hundert Threads, veraltet ist. Selbst wenn für jede angeforderte Datei ein Thread gestartet wird (und das ist weder bei HTTP 1.1 noch bei einem Gameserver der Fall) skaliert das ganze noch sehr gut und der Verwaltungoverhead ist durch moderne Scheduler nicht spürbar.

Außerdem wird die Entwicklung in Zukunft immer mehr in diese Richtung gehen. SUN macht es mit ihren SPARC Prozessoren vor. Dort werden bis zu 64 Threads auf einem Kern gleichzeitig bearbeitet. Da die Threads nciht besonders anspruchsvoll sind, ist das ganze verdammt schnell. Auf jeden Fall um längen besser, als mit nur einem Thread zu arbeiten.

[donelik]

http://getmangos.com/community/

Freie World of Warcraft Server nutzen MangOS als Basis. Wie genau das dort funktioniert weiß ich leider (noch) nicht. Bin selbst noch dabei meinen eigenen MangOS Server aufzusetzen.

VG
donelik

[DSG]

Das es zur Zeit noch nicht üblich ist, ist keine Begründung dafür, das es schlechter ist bzw. in Zukunft nicht der bessere Ansatz sein wird.

Durchaus. Ich spreche hier auch nur von meinen Erfahrungen. Wie ich schon mal erwähnt habe ist die Multithread Programmierung sehr anspruchsvoll, da diese schwierig zum debuggen ist und es mit locks/mutex/semaphores/usw.. zu unvorsehbarem Verhalten kommen kann. Damit ein Server stabil läuft müssen solche Punkte minimiert werden. Wenn ich einen Thread nur brauche als Dispatcher, also Nachricht empfangen und in eine Queue schmeissen, dann kann ich auch einen Thread verwenden und mit select() arbeiten. Bei 100 Threads macht sich dann der Context Switch bemerkbar. Wie dies auf neuen Server (64bit & Co.) verhält weiss ich nicht, hab ich noch keine Erfahrung damit.

Warum soll ein select() schneller sein, als 100 blockierte Threads von denen ab und zu mal ein paar wirklich etwas machen?

Ich bin mit dir einverstanden, dass man auch einen GameServer entwickeln kann mit einem Thread pro Client. Da kommt es dann darauf an ob die Threads eben nur als Nachricht Dispatcher arbeiten oder auch Spiellogik verwalten. Falls du in 100 Threads auch Spiellogik abarbeitest, ist die Synchronisation des Spielstatus sehr anspruchsvoll.

Da bleibe ich lieber bei meinen paar Threads die das ganze Sequentiell verarbeiten.

[odenter]

Also eigentlich ne Mischung aus P2P und Client/Server.

Die SessionManager überwachen die ZonenServer, wohingegen die ZonenServer untereinander ruhig P2P mässig reden können, weil z.B. ein Client von einem Server auf den nächsten wechselt, wobei es egal ist wie eine Zone konkret aussieht.

Dann hätte man auch nicht das Problem, damit es performant bleibt, jeden Client in einem Thread behandeln zu müssen, weil sich die Clients ja sowieso schon auf mehrere Prozesse verteilen. Und man durch weiteres splitten von Zonen auf neue Rechner die Performance praktisch nahezu beliebig erhöhen kann, das gefällt mir glaube ich. :)
Thread-Pools kann man in einigen Bereichen ja trotzdem verwenden, das ist ja nicht der Akt.

Wenn natürlich alle in eine Zone wollen, dann wars das, aber das kennt man ja von online Spielen, ist also eigentlich nichts neues.

[DSG]

Das Problem mit "alle Spieler in einer Zone" tauch auch bei AAA-Games wie WoW auf, ab einer bestimmten Anzahl Spieler fängt es an zu "laggen".

Die Server mit Hardware zu ergänzen ist sicher eine Möglichkeit, wenn dies nicht schon geschehen ist. Oder man überdenkt nochmals das Spieldesign, so dass man z.B. Questgeber in der ganzen Region verteilt und nicht alle am gleichen Ort hat. So verteilen sich die Spieler automatisch.

[odenter]

Ja klar, es soll ja nicht so sein das alle auf einem Haufen rumlaufen, wäre ja auch ein langweiliges Spiel. :)

Und nach was für Regeln würdest Du dann die Zonen einteilen? Wäre bei Dir jede Zone ein "abgeschlossener" Bereich, aus dem man nur wechseln kann in dem man von ZoneA nach ZoneB wechselt, also mit kurzem Ladebalken z.B.?

[Chromanoid]

In diesem Zusammenhang sollte man sich auch http://www.projectdarkstar.com/ zu Gemüte führen. Ziel des von Sun betriebenen Projektes ist ein skalierbarer "MMO Gaming Server" (Server Framework in Java). Das Projekt ist mittlerweile bei Version 0.99 angelangt, Sourcecode ist frei verfügbar. Wenn Oracle da nicht zwischenfunkt, wird das Ding mit ziemlicher Sicherheit das angenehmste System für Hobbyentwickler, um überhaupt ein MMO auf die Beine zu stellen.
Beim SGS/PDS (Sun Gaming Server) wird insbesondere versucht sich gerade von Gedanken wie räumliche Aufteilung für Arbeitsverteilung usw. zu trennen und Lastverteilung eben nach Last zu verteilen. Das Forum der Seite bietet interessante Diskussionen genau zu diesem Thema.

Im traditionellen Sinne werden ja MMO-Welten in Realms und Regionen aufgeteilt, um die sich dann jew. bestimmte Server kümmern. Im Hintergrund steht eine allmächtige Datenbank, die von Monster-Positionen bis Gegenstände alles enthält. Dabei läuft die Kommunikation zwischen Clients und Server in einer abgeschwächten Form von Transaktionen ab... Der Client "abonniert" beim Server Informationen, wie NPCs und deren Bewegungen in einem Gebiet. Der Client interpoliert dann zwischen den einzelnen Zuständen, die er vom Server mitgeteilt bekommt. In etwas dynamischeren Szenen ist es deshalb oft so, dass jeder seine eigene individuelle "interpolierte" Sicht auf das Geschehen hat. Besonders ist mir das immer bei FFXI aufgefallen: Wenn man da als Gruppe durch die Lande zieht und nicht allzu großen Abstand hält, sieht sich jeder auf seinem eigenen Client die Gruppe anführen, da die Informationen über die Positionen der anderen Spieler immer etwas hinterher hinken.... (weiß aber nicht ob das immer noch so ist)... Ich denke nicht, dass traditionelle Systeme für jeden Client einen Thread eröffnen. Wahrscheinlich wird es eher eine Menge von "Update-Threads" geben die auf verschiedene Events, die von Spielertransaktionen ausgelöst werden, reagieren...

Beim SGS ist das Hauptziel für Entwickler eine Umgebung zu schaffen in der Sie so tun können, als ob sie einen einzigen Server programmieren. Dieser hat Zugriff auf alle Daten usw.. Das SGS-Framework soll es dann ermöglichen, mehrere Server zu starten, die in diesem Sinne zusammenarbeiten ohne dass man das explizit einprogrammieren muss. Man soll einfach weitere Server starten können (in der Konfiguration der Server lediglich Serveradressen u.Ä. ablegen) und so die Leistung des Game-Server-Systems einfach skalieren können. Genau das funktioniert natürlich noch nicht so gut, ist aber ganz oben auf der ToDo-Liste.... Wie dieses System der automatischen Last-Verteilung funktionieren soll, weiß ich leider nicht aber es gibt ja schon ähnliche Ansätze wie terracotta und andere Clustering/Distributed Computing Frameworks...

LG
Christian

[DSG]

Und nach was für Regeln würdest Du dann die Zonen einteilen? Wäre bei Dir jede Zone ein "abgeschlossener" Bereich, aus dem man nur wechseln kann in dem man von ZoneA nach ZoneB wechselt, also mit kurzem Ladebalken z.B.?

Wenn jede Zone ein eigenständiger Bereich ist, vereinfacht dies die ganze Angelegenheit. Beim wechseln der ZoneA in ZoneB kann sich der Client ruhig mit der neuen Zone verbinden und kann ein Ladescreen einblenden.

Will man dies aber "seamless" machen, also ein fliessender übergang von A nach B ohne Unterbruch, ist dies schwieriger. Am Rand der Zone muss der Client auf dem Server A und B existieren, ein Ghost-Objekt, damit alle anderen Spieler von Zone A und B den Splieler am Rand sehen. Ist nicht ganz trivial zum implementieren.

In diesem Zusammenhang sollte man sich auch http://www.projectdarkstar.com/ zu Gemüte führen

Interessantes Projekt, ich muss mich da mal genauer Informieren.

[Chromanoid]

Ich würde wirklich nicht versuchen, die Welt in Regionen aufzuteilen und dann die einzelnen Regionen von Servern einzeln verarbeiten zu lassen. Das führt einfach zu suboptimalen Ergebnissen... Ich zitiere mal aus dem Project Darkstar Forum aus dem Thread "Why Darkstar does not partition the world?":

Classic MMO geographic partitioning is a VERY bad, wasteful way to try to laod balance.

It would work well if people were gaussian but they are not, they are one of the most anti-gaussian things around. People are social-- they clump, The result is that geographic partioning results in a mismatched mess of over loaded and under-used servers.
[...]
Instead, the whole concept behind Darkstar is based on dynamic discovery of user access patterns to data and assigning them on the fly to nodes to be processed. CPU is assignd to actions on the data rather then to hard pre-partitioned hunks of data. This means no servers are sitting idle, they all get used to process whatever parts of the world are actively being acessed. It also means you are never locked out of a region because it already has too many people in it. Finally, it provides full fail-over as any node can take up the job of any other failed node at any time.

[DSG]

Da bin ich natürlich einverstanden, dass die Raumaufteilung unabhängig von der Serverlast sein sollte. Doch ein dynamisches Loadbalancing, das die Prozesse und Server optimal auslastet, ist nicht unbedingt trivial zu implementieren.

Es kommt immer darauf an was für ein Projekt man anpeilt. Für kleinere Games macht es sicher Sinn, ein einfacheres System zu implementieren als ein sehr aufwändiges Load-Balancing System zu entwickeln. Wenn man aber ein grösseres MMO(RPG) Plant, sollte man genug Zeit in das Serversystem investieren und auf Frameworks wie Darkstar zurückgreifen. Doch in der Hobbyetwicklungs-Szene sind MMOs oft zum scheitern verurteilt und da liegt es oft nicht an der Serverimplementation sonder es fehlen andere wichtige Ressourcen.

[Chromanoid]

Doch in der Hobbyetwicklungs-Szene sind MMOs oft zum scheitern verurteilt und da liegt es oft nicht an der Serverimplementation sonder es fehlen andere wichtige Ressourcen.

das ist wohl wahr ^^

Ohne hier Werbung für Darkstar machen zu wollen, kann man das System wohl auch ohne weiteres für kleine Teams und Hobbyisten empfehlen. Gerade für kleine Projekte... Jemand hat zum Beispiel (kommerziell) mit einem wohl recht kleinen Team eine Flash-Spiel-Seite mit Darkstar realisiert und ist wohl von den Ergebnissen begeistert. Die Flash-Spiele kann man alle im Multiplayermodus spielen (in kleiner Runde)... (http://www.campfu.com)

[odenter]

Um zwischen einem Indoor-/Outdoorbereich zu wechseln, kann man ja Zonen bauen.

Wenn ich mich dann aber im Outdoorbereich befinde, dann könnte man natürlich eine Art Lastenverteilung machen ala 1 Server Prozess für jeweils 500 Clients, kommt der 501 Client wird ein neuer Serverprozess gestartet und der Client hängt dann eben an diesem etc., wobei jeder Server immer die gesammte Welt (in dem Fall Outdoor) darstellt, zumindest wäre das realtiv simpel.

Allerdings hält dann jeder Prozess tatsächlich alles vor, wenn auch nur für einen Teil aller Clients.

Das gleiche ginge natürlich auch für den Indoorbereich, jenachdem wie groß dieser ist. Wenn dann allerdings Client 1 vom Server 1 mit Client 540 von Server 2 chatten will, dann müsste die Kommunikation über einen zusätzlichen "Verwaltungsserverlaufen" (verteilt auch die Clients auf die Server), oder die Server reden P2P mässig, damit das dann performant wäre müssten aber alle Server wissen wer wo ist, ansonsten artet das ja in ständiges Fragen aus (S1 an S2 ist Client 1050 bei Dir? Antwort nein, S1 an S3 ist Client 1050 bei Dir? Antwort ja).

Ich habe hier http://www.ibm.com/developerworks/archi ... #resources einen Artikel von IBM gefunden.

[kniglifix]

Es gibt das Spiel Battleground Europe (vormals WWIIOnline), ich weiss nicht ob das vielleicht einer kennt. Es ist ein MMOFPS das vom spielerischen her keine Zonen kennt. Man kann vom einem ende starten und zum anderen ende hin durchrennen ohne das es Netzwerkmäßig stottern würde.

Soviel ich mal gelesen habe, soll sich dahinter ein Cluster Netzwerk befinden. Aber viel weiss man auch nicht darüber. Zumindest gibt es diverse Basis Server die die Daten der klienten verarbeiten. Darunter auch ein sogenanter STO-Server, Server-Tracked-Object. Wenn sich was im Spiel bewegt und nicht klientseitig berechnet wird, so übernimmt der Server das und sorgt dafür das diese Objekte bei allen Klients dort sind wo sie sein sollten. Dazu kommen noch ein Anmelde Server und auch ein Chat Server. Aber letzterer scheint komplett getrennt zu sein, so kann es einem passieren das der Chat-Server abstürtzt aber man sonst ganz normal spielen kann.

Der Anbieter von dem Spiel rückt keine genauen Zahlen raus, geschätzt wird aber das im Schnitt zwischen 1000 und 2000 Spieler Online sind.