Beiträge von Booksize

Kann ich nicht beurteilen.
Auf jeden Fall hat meine Rev 9199 weniger Klassen-, Spellbugs als Mangos :)
Und was die originale TDB hat kann ich nicht mehr sagen, denn was Bugged wird bei uns korrigiert.
Meine DB ist eh nen zusammenspiel aus 3 DBs, viel arbeit der DB-Dev und meiner wenigkeit.

Aber wenns mich nicht täuschte war die originale TDB und Core bugfreier als Mangos, denn diese hatten wir zuvor (und es war ne sch*** arbeit die CharDB auf Trinity anzupassen).

Ich liebe wenn das Niveau der Nachrichten sofort auf das Niveau der Bild sinkt.
So lange ne Storry ausschlachten bis nix mehr geht.
Dieses Bakterium ist nicht gegen alles resistent, man sagt es um so schnell wie möglich wieder Millionen kassieren zu können wie bei der Schweinegrippe.
Denn lassen wir mal das Szenario fortschreiten und die ersten Leute sind in Deutschland bedroht, man kann davon ausgehen, das man iwie 2-3 Wochen/Monate später nen Antibiotikum in der Hand hat.
Das als vortschritt preisst, dabei nichts anders verwendet als was schon bekannt ist.
Aber naja, was solls so macht man Geld.
AIDS ist natürlich nen anderes Kaliber, nen netter Retrovirus (und ich will nicht wissen werden gezüchtet hat, natürlicher Ursprung währe mit der Gleichgewichtstheorie zu erklären).

Aber das Ding wird wieder sowas wie Schweinegripe, man hat halt Blut geleckt und was in der Natur des Menschen steht, man wir gieriger.

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 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

Verwechselst du Trinity mit Mangos?
Eine TrinityDB für 333a mit kompletter Überarbeitung ist schwer zu finden.
Das was du halt machen kannst, ist einfach dir die TDB aus der Repo zu ziehen, die 333a einzuspielen und anschliessend selbst zu fixxen.

Vielleicht kann man die Spawnes von ICC aus der YTDB ziehen und dort einschreiben.

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

sicher hat Linux genauso damit zu Kämpfen, leider ist Chuck Norris nicht Linux kompatibel und benötigt ein Crosscompile -.-
Der sich aber sich auf Grund der meist inkompatiblen und sehr heiklen Norris(c) API negativ aufs System auswirken und jeder Connection, bei unsachgemäßer Behandlung, einen instant Roundhousekick verpassen kann.

Aber es hilft schon mal die jungs einfach innen Drop zu packen und die Pakete bei erfolgreichen Handshake zu verwerfen.

Synflood sind da echt mal ausgenommen, die bekommt man leider nicht so schnell weg.
Aber nen DDoS sollte es schon ein "bisschen" aufhalten (es sei denn es kommt von einem großen Botnet).
Selbst wenn, dazu kann man LoadBalanced Server fahren, nutzt aber nur was bei WebSites, leider nicht bei GameServern.
Wenn die im Attack stehen, kann man nur hoffen das derjenige nicht alle Server im Fuhrpark angreift.
Wenn er nicht alle angreift einfch zum nächsten umlenken (zumindest bei WoW), schon gehts weiter (gesetzt des Falles man hat die DBs und Emus syncron auf allen).

Aber wie gesagt sind beide in Beschuss dann ist damit auch essig.

unter Linux geht das ganze recht einfach.

Einfach fail2ban drauf, die Filter anpassen und ggf. eigene schreiben, dann die Banzeit einstellen und ruhe ist erstmal.
Falls derjeinge dann noch nen Permban haben möchte, einfach nen Script bauen, was das F2B log durchscanned und neue banned IPs aufnimmt.
Diese anschliessend in die IPtables eintragen.
Dann kann der mit seinem Server scannen bis er schwarz wird.

Bei Angriffen auf die Console zieht F2B auch ganz nett.
Wichtig ist, das man eine IP in den Logs sieht, dann kann man sowas (fast) immer ganz bequem bannen.

LG GiR-Blunti