Chaosduckman;179059 schrieb:

Ich glaube nicht das ich euch helfen kann, aber was meint ihr mit Core und TrinityCoreX: USAGI xD

Core sind die sogesagten "Files" von WoW also der Emulator und TrinityCoreX USAGI ist ein abgeschnittener Zweig von Trinity Core. Trinity Core ist auch ein Emulator.

Jep, Usagi ist die Nachfolgecore von der Yumi.
Hatte beide Cores gebaut um Erfahrung im Bereich des Clusterns zu sammeln.
Yumi war die erste auf der ich das Map<->Cluster System eingebaut und getestet hatte.
Anschliessend hab ich das ganze auf 333a neu erstellt und dabei Änderungen am Paketrouting und der Auswertung der zurückkommenden gemacht.
So sind dann nach und nach ein paar neue Klassen und Routinen hinzugekommen und das Routing an für sich wurde etwas vereinfacht.
Weil nun aber schon die Zeit von 3.3.5a ist, würde ich gerne diese Technik komplett auf der TrinityCore Rev 9199 anwenden und diese Core einsatzfähig im Cluster-betrieb haben.

Der Anfang währe hier erst einmal eine Core so umzuschreiben, das sie als BG-Core funzt (quasi WoldServer vermittelt an BG server).
Später kommt dann wieder das ganze auf Map-Clustern raus.

Ist halt mal was anderes als die single Cores.


LG GiR-Blunti

Das System ist ähnlich was Blizzard nutzt.
Du connectest als erstes auf Realmserver, holst dir die Realmlist.
Von diesen wirst du auf einen Logonserver vermittelt, welcher (im Fall der Yumi und Usagi) aber nur die Playerposition, Items und ein paar andere Dinge speichert, aber nichts berechnet.
Je nachdem auf welcher Map du dich befindet werden deine Daten an den jeweiligen Cluster zur berechnung geschickt, welcher dann die Monster Movements, sowie auch alles andere ausrechnet, die Pakete fertig macht und wieder an den Logon zurückschickt und dieser anschliessend an dich.

Somit wird die Welt nicht von einem Server gestellt, sondern von vielen.
Das ganze hat Vor- und Nachteile.

Nachteil:
- leicht höherer Ping
- mehr Ressourcen für den Server notwending (wenn man im mehr Cluster betrieb arbeitet)

Vorteil:
- LogonServer ist backupserver, fällt ein Cluster aus hat der LogonServer die Item- und ein paar andere Daten und somit geht so gut wie nix flöten
- Crashed ein Cluster, dann reissts nicht den ganzen Server down
- Man kann Inzen in der laufenden World debuggen und braucht keine Testcore dafür
- Man kann mehr Player verwalten und berechnen lassen


Schematisch ausgedrückt läuft das so:
Client -> Realmserver (sendet IP)
Client <- DATEN -> LogonServer (Hat Map zuweisung) <- DATEN -> Cluster

LG GiR-Blunti

Das mit der Sendelast stimmt schon, ist aber nicht weiter tragisch, weil selbst die normalen single Cores auch knapp 2500 und mehr fassen können.
Meist werden sie einfach durch ihre Berechnungen für die Map gebremst.
Der Logonserver in dem Fall berechnet ja nix, ausser das Routing und neu verpacken der Daten.
Das Senden der Playerdaten läuft auf einem oder mehr Threads, genauso wie das Senden und empfangen der Clusterdaten (genauso wie die single Core das ja jetzt schon macht).
Der Cluster selbst sollte dafür auch nen Threading bekommen (quasi Chilprozesse auf denen er die Lasten verteilt).
Wobei dieses mein jetziges Problem ist, weil ich mit ACE mal so gut wie kaum umgehen kann, aber weiss das es geht.

Schematisch:
Client->Logon (Thread I)->Cluster (Thread I)
Client->Logon (Thread II)->Cluster (Thread I oder II)

Genauso gehts auch wieder zurück.

Nun kann man eben so viele Player aufnehmen, bis die 1Gbit Leitung voll oder Logon wirklich am Ende ist.
Die jetzige Core könnte mit einem single Socket knapp 500Spieler pro Cluster vermitteln, der Cluster wirft alle Daten in die jeweilige Queue und weiter gehts.
Der LogonServer schafft aber selbst mehr als 2k zu verwalten.
Es ist wirklich nur die Verbindung zum Cluster die verbessert werden muss, leider hab ich einen umständlichen Weg gewählt und hab die Listenener im Logon und die Connectoren im Cluster und nicht umgekehrt.
Was aber eine kleine Sicherheit bietet, weil man so nicht einfach in den Clusterstream einhacken kann, hier müsste man seinen Hack auf den Logonserver machen, was aber aufgrund einiger geplanten oder schon vorhandenen technisch bedingten Sachen nicht ohne weiteres möglich ist.

Das Verschlüsseln würde ich mit einem T- oder standart XOR-Verfahren machen, weil beide recht unverbreitet sind.
Einen rotierenden Schlüssel der bei jeder Transaktion weiter generiert und auf den ersten aufbaut.
Damit ist schonmal auf die schnelle nix zu machen.
So sollte die Leitung sicher sein, weil man nun den InitKey braucht um einen Cluster vorgaukeln zu können, der nunmal nicht mitgesendet wird xD
T-Code oder 3PairCode ist zu aufwändig und auch schwer zu handlen (z.b. A12BDx98DF2x67BCA, so in etwa würde der Code aussehen ein 3x5er standart)

Wie genau das mit dem XOR abläuft möchte ich lieber nicht erläutern...

Naja, das KeyLess XOR hab schon im Feldversuch gehabt.
Funzte einwandfrei, ist mir vor Jahren in der Schule im Unterricht eingefallen.
10 Jahre später hab ich das ganze mal innem Programm umgesetzt.
Ist auch nicht schwierig oder gar kompliziert und ressourcen fressend aber fürs erste Wirkungsvoll :)
Das Probelm ist nur das die Counter syncron laufen müssen, was aber nicht weiter Tragisch ist, weils relativ einfach zu lösen ist.
Dumm nur, wenn jemand den Einsprung und den Faktor hat, ab dem Moment nutzt das ganze nix mehr, denn dann muss man neu modulieren.

Welche Tabelle es ist, bekommt man schnell raus, jeder Computer hat sie, jeder nutzt sie, aber kaum einer weiss das sie Statisch basiert xD

wo kann ich c++ lernen ^^ ? :playingsmiley: