Ich konnte es nicht lassen, also hab ich mich mal wieder daran gesetzt und eine TrinityCore geclustert.
Nun stellen sich sicherlich einige die Frage was ist ein Cluster und was kann er?

Ein Cluster ist recht einfach zu beschreiben:
- Man kann die Wold auf viele Server aufspalten und hat somit einen guten Lastenausgleich
- Man kann mehr Player auf einem Realm fassen (single Cores 2-4k Cluster 8-12k)
- Stürzt ein Cluster ab, dann crashed wenigstens nicht die ganze World
- Man kann einen Cluster-Server ondemand abschalten und durch einen neuen ersetzen (falls mal ein Teil in der World bugged)
- Der LogonServer wird gleichzeitig BackupServer sein, d.h. das Teil speichert die wichtigsten Sachen mit
- Man kann auch sehr leicht die Welt um eigene Maps erweitern, man muss nur dem standartsystem die Accespoints (wahlweise mit Portalen) zuordnen und dem Client seine gemoddeten Files geben

Okay, nun muss ich zugeben, das alles kann die neue Core noch nicht, bis jetzt ists ne pre alpha die ich aus der USAGI heraus gebaut habe.
Diese Core baut auf der MythCore auf, welche wiederum ein Ableger der Trinity ist und wenn das Ding final ist dann kann witzig werden.

Geplant sind z.b.: Realmpools für BGs und Inis die man auch Projektübergreifend machen kann (da müssen sich aber die Projekte selbst einig werden wer den PoolMaster hat)

Die Core hört auf den CodeName Namiko was soviel wie Welle (Wasser) heisst.

Zu finden ist das Teil unter:
zippo / Trinity_Namiko / overview — bitbucket.org
Viel Spaß beim Compilen, basteln und experimentieren.
Wer natürlich Lust hat mir bei der Core zu helfen ist herzlich dazu eingeladen, die Ziele die ich oben genannt hatte sind nicht zu hoch gesteckt und auch umsetzbar.
Es hört sich immer alles schwieriger an als es ist :)

Achso, wer sich für die VorgängerCore interressiert sie hat den CodeName Usagi (Hase) und ist hier zu finden:
zippo / Trinity_USAGI / overview — bitbucket.orgMit dieser Core und Yumi hab ich die ersten Erfahrungen in diesem Bereich gesammelt, wobei sich Yumi doch eher an die Spourius Emu orientierte, welche im C++ relativ ineffektiv war.

LG GiR-Zippo

PS: USAGI konnte schon die grundlegenden Routings und komplettes Map-Clustering, leider bin ich nicht mehr dazu gekommen die ganzen GUID-,Gruppen-,Time-Syncs umzusetzen, die leider auf dem Cluster need sind, damit alle Cluster/Nodes das gleich Wissen haben.
Hier mal ein Bild vom LogonServer und dem Cluster_A im Betrieb (noch USAGI):

Es gibt neues:
Werde nun im laufe des Tages Namiko das initialrouting einbauen, damit ist dann das Map-ClusterPorting drinnen.
Anschliessend werden die ChatCommands aufgeteilt.
!=LogonServerCommand
.=ClusterServerCommand

Das ganze wird dann mit "ADD: InitialRouting implemented" im Commit stehen, ab dann sollte die Core ihr routing können und man kann seine ertsen spielereien auf dem Cluster machen.
Als kleine Bitte verweg, nehmt vorischtshalber Windows, denn ich weiss nicht ob die Core noch die negativen Folgen eines Deadlocks hervorrufen kann (USAGI machte dies leider und war deshalb unter Linux unbrauchbar).

LG GiR-Blunti

ADD: InitRouting ist drinnen, die Commands sind so aufgeteilt wie es oben steht.
Bis heute abend werde ich die überflüssigen Object- und Creature-Spawnes aus dem LogonServer entfernen, dann kann man endlich mal das ding ohne Hilfsbetrieb anlaufen lassen.
Abschliessend werde ich hier noch ein kleines Tut anfügen, damit man auch in etwa weiss, wie man das Ganze in der DB und im System einstellt.

Später wird dann auch USAGI komplett von BitBucket gelöscht und wenn alles glatt läuft dürfte Namiko bald bei und von MythCore unterstützt, weiterentwickelt und "vertrieben" werden.