Meine Gedanken um das Problem mit der Garnison

http://www.surfer-haben-rechte.de/content/blizzard-lenkt-ein *blinzel*

Meiner Ansicht nach ist es weniger ein Hardwareproblem, sondern eher ein Softwareproblem. Daß Hardwareprobleme zusätzlich mit reinspielen und die Sache schlimmer machen, ändert meines Erachtens nichts am Kernproblem, daß die Instanzierung der Garnison nicht sauber genug programmiert wurde.

Darauf deutet hin:
1. Die meisten Probleme bestanden beim Betreten der Garnison, und zwar egal von welchem Punkt aus.
2. Als Fehlermeldung wurde ausgegeben: "Transfer abgebrochen - Instanz nicht gefunden".
3. Wenn man es mal geschafft hatte, in die Garnisonsinstanz reinzukommen, konnte man praktisch beliebig lange darin bleiben und hatte keine Probleme. Außer manchmal beim Versuch, sie wieder zu verlassen.
4. Ein anderes Problem (z.B. FoLi-Alliseite) bestand darin, daß alle(!) Spieler in derselben Instanz der Garnison waren.
5. Die Probleme mit den Instanzservern, die eine Zeitlang gleichzeitig auftraten, waren laut Bluepost auf eine DDoS-Attacke zurückzuführen.
6. Wiederholte Versuche, die Garnison zu betreten, führten normalerweise dazu, daß es irgendwann funktionierte, und innerhalb der Garnison gab es meist keine Funktionseinschränkungen.

Wenn es tatsächlich ein Sizing-Problem wäre, hätte 6 nicht funktionieren dürfen und es hätten überall dieselben Probleme auftreten müssen, die evtl. in Warteschlangen resultiert hätten. Meiner Ansicht nach ist der Programmteil, welcher beim Übergang vom Kontinent-Server auf den Garnisonsserver aufgerufen wird, unsauber programmiert worden, was dann zu den nicht korrekt generierten bzw. nicht erreichbaren Garnisonsinstanzen geführt hat.

Ich werde mal versuchen, es technisch darzustellen:
Wir haben eine Datenbank, in der alle Charaktere gespeichert sind, und in der der Charakter definiert ist. Das könnte so ähnlich aussehen.

Beim Einloggen ins Spiel wird der Datensatz des Charakters geladen und in die temporäre Datenbank des aktiven Realms geschrieben (was auch der Grund ist, daß das Arsenal immer erst nach dem Ausloggen aktualisiert wird).

Nun überschreitet der Charakter mit seinen Koordinaten die definierte Schwelle, ab der die Garnison beginnt. Was dort dargestellt wird, ist aber individuell für diesen Charakter und muß daher jedes Mal beim Betreten neu generiert werden anhand von Parametern aus der Datenbank. Es muß also nach den Garnisonsparametern geschaut werden.

Aus diesen ganzen Daten (und das sind ziemlich viele, zumindest Flags für die ganzen Gefolgsleute, Gebäude, Ausbaustufen, aktive Aufträge, Quest-NPCs, Erz- und Kräutervorkommen etc.) muß innerhalb der paar Sekunden, die der Spieler für den Übergang braucht, eine komplette Instanz aufgebaut werden. Diese wird ebenso in eine neue temporäre Datenbank geschrieben, von der dann die grafische Aufbereitung erfolgt. Und wenn genau dieser Aufruf fehlerhaft ist, stürzt das ganze Konstrukt in sich zusammen.

Angenommen, der Aufrufbefehl liest den Datensatz des Charakters aus und speichert die Werte in Variablen, aus denen heraus der Instanzgenerierungsbefehl seine Parameter erhält. Sobald der Befehl erfolgreich ausgeführt wurde, müssen die Variablen wieder gelöscht werden, da ansonsten Restdaten die einzulesenden Daten des nächsten Datensatzes korrumpieren können.

Oder der Klassiker, daß die Daten aus der Datenbank in nur einen String gedumpt werden, dieser jedoch fehlerhaft ausgelesen wird. Aus obigem Beispiel wäre das:
"12345SunyaraH211Juwe2"
Und natürlich wäre der String um ein vielfaches länger, je nachdem wieviele Parameter tatsächlich übergeben werden müssen. Sollte sich nun zum Beispiel ein zweiter Charakter in die Garnison bewegen, der eine andere ID hat, wo dieser Fehler nicht abgefangen wird, könnte es wie folgt aussehen:

Wie man sieht, ist die ID von Orci nur 4 Zeichen lang. Wird der Fehler nicht korrekt abgefangen, passiert folgendes:
String Sunyara: "12345SunyaraH211Juwe2"
String Orci: "5432OrciH1000"
Das System, welches stumpf die ersten 5 Zeichen des Strings als ID abgreifen würde, würde nun versuchen, das "O" als Zahl zu interpretieren und auf einen Fehler laufen, die Instanz könnte also nicht generiert werden. Es müsste also eine "0" vor die ID von Orci eingefügt werden, um das Problem zu beheben.

Ebenso könnte es passieren, daß Zeichen von längeren Strings in die nachfolgenden überfließen und dort für chaotische Werte sorgen. In jedem Fall würde die Generierung der Instanz entweder nicht erfolgreich abgeschlossen oder es würde eine Instanz generiert, die aber nicht gefunden werden kann, weil die ID der Instanz nicht mit der ID des Charakters übereinstimmt. Alle paar Durchgänge würde es sich vermutlich wieder ausgleichen, so daß immer mal wieder die richtige Instanz generiert und der Charakter dorthin übertragen werden könnte.

Solche Kleinigkeiten sind aufgrund von Flüchtigkeits- und Formatierungsfehlern bei der Erstellung von Programmcode leider nicht wirklich selten, und diese dann nachträglich zu lokalisieren, ist alles andere als leicht und schnell. Aufgrund der begrenzten Anzahl an Betatestern kann es so ein Fehler durchaus auch mal durch die Beta und in den Livebetrieb schaffen, dafür gibt es genügend Beispiele außerhalb von WoW.

So, sehr technisch, stellenweise etwas vereinfacht, aber das ist ungefähr meine Erklärung. Falls mir noch irgendwer folgen konnte.

Naja Suny ich glaube nicht das es so ein Programmierfehler war davon mal abgesehn wer sowas in nen String schreibt gehört geschlagen..... Für sowas wurden arrays erfunden ... (ich weiss arrays sind aneinanderkettungen von Strings). Ich denke einfach das eine Überlast beim Instanzierungsserver gab. Blizzard hat zwar mit andrang grechnet aber bestimmt nicht gedacht das sie es wieder auf 10 Mio abbos Schaffen.
Überlastung klingt deshalb für mich logisch da zum einen die Instanzserver ebenso betroffen waren und zum anderen hatte ich sowas schonmal bei nem SQL Server der hatte ebenfalls nur sporadisch(beim gleichen SQL Statement) ergebnisse geliefert, da die Server überlastet waren, lief die SQL Abfrage in einen Timeout.
Sprich der Server war mit der Menge der Anfragen überlastet und nicht mit den eigentlichen Daten.

Sobald diese ausgelesen sind, werden diese Sicherlich (so meine Vermutung) Über nen Workbalance System verarbeitet.

Zitat von Aiox

Überlastung klingt deshalb für mich logisch da zum einen die Instanzserver ebenso betroffen waren und zum anderen hatte ich sowas schonmal bei nem SQL Server der hatte ebenfalls nur sporadisch(beim gleichen SQL Statement) ergebnisse geliefert, da die Server überlastet waren, lief die SQL Abfrage in einen Timeout.
Sprich der Server war mit der Menge der Anfragen überlastet und nicht mit den eigentlichen Daten.

Okay, das klingt auch plausibel. Daß sie den Server, welcher die Instanzgenerierung (nicht die eigentliche "Runtime") zu klein dimensioniert haben und dadurch die Statements im Timeout gelandet sind. Und vermutlich den Teil auch nicht so einfach erweiterbar bzw. flexibel für Lastausgleich gemacht haben, sonst hätten sie nicht so lange gebraucht, um das Problem zu entspannen. Da ist garantiert irgendwo ein Coding-Problem dazwischen. Wenn die in der Beta z.B. nur eine Instanz eines Instanzgenerierungsdienstes geplant haben, weils dort ja ausgereicht hat, hat vielleicht irgendjemand vergessen, daß man für den Livebetrieb dort auch Flexibilität braucht, und einfach vergessen, eine Lastenausgleich-Option einzubauen. Wär nicht das erste Mal, daß es bei komplexen Programmen an solchen "Kleinigkeiten" hapert.