Die Banshee ist los :)

[Kent_Brockman]

Hi ihr ganzen WoW-Emu-Nerds da draußen


Wie einige ja vielleicht wissen gehe ich bei Servercrashes gerne etwas andere Wege, was dazu geführt hat das ich nun einen etwas anderen WoW-Emu bastel.
In meinem nächtlichen Schlafentzug hab ich das Ding mal Banshee getauft, es hört auf den Codename Ayumi und läuft auf Patch 335.

Das ganze System soll so nah an Blizzard ihrem System laufen wie möglich, d.h. Blizzard nutzt Cluster also bastelt man sich sowas auch.
Auf dem OpenSource-Markt gibts so eine Core nicht wirklich (außer die von Raczman, die ja leider nicht weiter gebaut wurde, Spurious und meine alte Core), obwohl so ein Cluster doch einige Vorteile bringt im Gegensatz zu den jetzigen Cores.



Weil mein Kaffee noch nicht durch ist und mein Compiler auch noch ne Runde braucht, erkläre ich ein bisschen was so ein Cluster macht und zähle ein paar Vor- und Nachteile auf, damit man soch ein Bild machen kann was so ein Cluster überhaupt kann.

Das Sytem an dem ich bastel stellt einen klassischen Map-Cluster dar.
Das bedeutet jede Map kann auf einem anderen Server laufen, man kann natürlich mehrere Maps von einer Node bearbeiten lassen.

Blizz ging hier offensichtlich eine Stufe weiter und nutzt eine Mischung aus Map- und Grid-Cluster, was eine noch feinere Aufteilung ermöglicht, aber für die durchschnittliche Spielerzahl von knapp 2k-3k reicht ein Map-Cluster vollkommen.

Ich hab mich hier für das Standartmodell entschieden:
RealmServer
LogonServer (Master)
WorldServer (Node)

Um einen Minimalbetrieb zu gewährleisten braucht man einen Master und eine Node.
Jede Node stellt einen Teil der Welt bereit, je nachdem welche Map auf sie verweist, in dem Fall ist es nur eine Node die hier die ganze Welt darstellen würde.
Das diese Konstellation totaler Schwachsinn ist kann man auf einem Blick erkennen, denn man kann hier auch eine SingleCore einsetzen.
Aber nun kommt der Clou, setzt man nun noch eine Node ein und meldet sie in der DB an, so wird der Logon beim betreten der Map, die auf diese Node zeigt, einfach die Daten des Spielers auf die Node umlenken.

Lustig ist wenn die Node abstürzt so ists dem Spieler egal, er wartet bis sie wieder online ist oder der Backup für gefunden wurde, die anderen Spieler die auf anderen Nodes zocken merken von dem Vorgang nix, für sie ist die Welt in Ordnung

Allerdings werde ich das nicht in Inzen durchsetzen, denn es ist fatal wenn auf einmal die Spieler vor einem respawned Boss stehen und nicht mal ready sind...
Denk mal da werd ich die Spieler einfach vor die Inze setzen und ne einfache MSG rausballern, damit sie bescheid wissen (Blizz wirft sie halt komplett ausm Game).

Na gut genug Text jetzt die Fakten.

Vorteile:
- Man kann kleinere (und vllt. billigere) Roots nutzen, dennoch muss ein etwas stärkerer für den Logon her
- Bei NodeCrash kein kompletter Server crash
- Bessere Lastenverteilung
- Man kann Inzen einfach "offline" nehmen und die Node compilieren und hochfahren und kein Spieler der auf der Welt ist merkts (außer die, die grad in die Inze wollen)
- Mehr Spieler als mit einer normalen Core verwaltbar
- DB-Ladezeiten verkürzen sich wenn man nur die Daten läd, die die Node für ihre Maps braucht

Nachteile (ja das gibts):
- Technisch anspruchsvoll
- für "kleine" Server (bis 200 Spieler) recht uninteressant
- Für viele ziemliches Neuland

Da fallen einigen bestimmt noch mehr Vor- und Nachteile ein, mir sicher auch, aber mein Compiler ist fertig


Jetzt ist die Core soweit gediehen das ich gerne demnächst einen Alphatest fahren würde und dazu doch einige Mitstreiter brauche die das ganze mal testen würden, denn alleine Testen ist doof -.-

Um gleich allen Leuten die nun sagen werden: "Bah das wirdn Projekt, nimm den Sticky" den Wind aus den Segeln zu nehmen.
Das ganze wird kein Projekt, ich mach das nur zum Zeitvertreib, ein bisschen weil ich der Herausforderung nicht wiederstehen kann und Spaß an der Sache habe xD

Was allerdings passieren wird, ist das ich wenn Interesse besteht die Core als fertig compiliertes System in regelmäßigen Abständen hier release.
Das wird aber nur passieren, wenn ich der Meinung bin das das Teil auch zumutbar ist.

Nochmal zum Test: Ich werde wenn ich soweit bin ihn zu fahren dann hier im Thread ankündigen, wer Lust hat an dem Teil mit zu proggen ist wie immer herzlich eingeladen.
Einfach per PM melden und schon geht alles seinen Weg, nur bitte beachtet das ich derzeit zeitlich etwas komisch angebunden bin.

LG Kent Brockman

PS: Falls falsche Sektion, bitte verschieben.

[saifi]

Hört sich sehr sehr schön an, währe aber toll wenn du das bei TrinityCore oder so erweiterst oder eine Anleitung rein stellst was man alles ändern muss damit es geht.

[°"Crazy"°]

saifi, eine Anleitung zum Cluster erstellen? Oder welche meinst du?

Solltest du zum Cluster die Anleitung haben wollen, musst du C++ können und selbst es schreiben. Dafür gibt es keine Anleitung.

[saifi]

ICh meine damit die C++ Files zur verfügung stellen, damit die leute die in ihre eigene core einbauen

[Kent_Brockman]

Nein die Sourcen werde ich nicht zur Verfügung stellen, nur die 32Bit Binaries.

Was alles geändert werden muss, um so eine Core zu proggen, liegt auf der Hand:

Als erstes brauchen wir ne 4. DB in der wir hinterlegen welche Map auf welcher Node steckt und eine Art Realmlist für unseren Master damit er weis ob die Node online ist und dich ggf. davon abhält auf diese Node zu spatzieren.

Dann braucht man im Master nen Connector mit dem man Verbindung zur Node aufbaut, idealerweise sollten das mehrere sein und am besten (um keinen Flaschenhals zu bekommen) sollte jede Session mit ihrem eigenen connector auf der Node sein.
Um dem ganzen aber etwas Einhalt gebieten zu können, hab ich das ganze in Threads gepackt.
Weswegen Listener und Connector async zu einander laufen.
Hat klar ein paar Nachteile, aber auch Vorteile.
Denn so kann ich ohne großen Aufstand einfach die Sockets zur jeweiligen Node closen.
Brauche beim Sessionrefresh nicht zu warten bis der Socket seinen wakeup hat oder bis er gesendet hat, denn das macht er wie auch der Listener im Hintergrund.



Ab dann kann man sich hinstellen und langsam eine kleine Mechanik zum routen einbauen und einen reconnect-mechanismus um die Client bei Bedarf wieder auf die Node zu bekommen.

Abgesehen von den ganzen Sync-Mechanismen um die Nodes syncron zu bekommen, wars das dann auch schon...

Aber ich werde heute schonmal die Vorbereitungen treffen um das Teil auf einer etwas größeren Maschine testen zu können und wenn alles gut geht dann hier durchgeben wie man da drauf kommt...

[saifi]

Ok und was bringt uns das?

z.B ich habe eine Cataclysm Core will aber den Cluster, du hast eine Core die vielleicht total Buggy ist und ich nicht benutzen möchte, es ist nur ein beispiel, und deine core ist vielleicht 335 und ich will aber auf dem aktuellen WoW stand fixxen etc. und habe selber meine fixxes und muss die selber in die source einspielen und habe einen Linux root was dann?

[Kent_Brockman]

Da bleibt dir eh nur eines übrig, du musst das ganze selbst erstellen...
Warum?
- Für Cata werde ich derzeit keinen Cluster schreiben, weil ich da kein Interesse dran hab
- Weil sich Skyfire nicht für interessiert und ganz andere Schwerpunkte hat
- Skyfire schneller geändert wird als ich den Cluster anpassen könnte
- Ich alle allein da stehe, egal ob ich die Sourcen hier offen lege oder nicht

Bei 335 muss man sich eben darauf verlassen das ich was von der Sache verstehe die ich hier mache um nicht später dauer downs zu bekommen.
Aber keine Angst diese Core ist wenn ich sie hier als Bin zum DL freigebe eh auf einem größeren Server in Betrieb...