Mod für PB-Spiele: PB Mod_v1

[Ramkhamhaeng]

Dagegen können wir leider nichts unternehmen.

Das Spiel ist so designt, dass alle Ereignisse auf allen Rechnern, die mit dem Server verbunden sind, in der exakt gleichen Reihenfolge ausgeführt werden müssen. Deswegen bist du bei jeder Aktion vor der langsamsten Verbindung betroffen. Das Spiel ist so lange unterbrochen, bis es weiß, dass auf anderen Rechnern in den letzten 0.25s* (+Lag) nichts passiert ist.


*Diesen Wert kann man per XML variieren. Es gibt als theoretisch schon eine Chance, dass bei PB-Spielen ein anderer Wert besser geeignet ist.

[Thorgal]

Ah ok. Groß am XML rumzuprobieren, bringt da mMn auch nichts. So schlimm ist das Warten auch nicht.

[Zulan]

In einer Story wird berichtet, dass die Linien des F4-Beraters verbuggt sind. Vorallem sind da viele rote Kriegs-linien, die da nicht hingehoeren. Ist das bekannt, bzw. kannst du das reproduzieren?

Edit: Habs Grad gesehen, das scheinst du ja zum 12. Januar gefixt haben. Hätte ich ganz vergessen. Waere die Frage ob wir mal wieder nen Versionsinkrement macht. Braucht das eigentlich nen serverseitiges Update? Ist ja Ui only.

[Frozen]

Also im Lan brauchten wir damals bei riesigen Karten auch gerne mal 5 Minuten bis die Karte transferiert wurde.

[Ramkhamhaeng]

Ja, behoben ist der F4-Fehler schon und es müsste nur die nächste Mod-Version verteilt werden. Können wir ja mal in nächster Zeit in Angriff nehmen.

@Zulan: Beim Aufruf der PHP-Seite hatte zwischenzeitlich einen SQL-Fehler erhalten. Da die Meldung nur einmal da stand wird das mit der Aufräum-Methode vom Cache zusammen hängen. Kannst du sicherheitshalber mal testen, ob die Datenbankgröße immer noch stärk wächst? Könnte sein, dass deine Modifikation das Problem nicht behoben hat.

[Ramkhamhaeng]

Ich rolle die neue Modversion gerade aus und beginne heute mit dem Testserver.
D.h. dieser wird dann nicht mehr mit Version 3 betretbar sein.

@Spieler des PB73: Bitte noch nicht beginnen die neue Version zu installieren. Könnte sich noch ändern und jede noch so kleine Differenz in den Spieldaten führt zum Crash…

[Zulan]

Ich wollte mir nochmal die netzwerk-throttling-sache anschauen. Hast du zufaellig schon rausgefunden in welchem Thread die Netzwerkroutine laeuft? Oder irgendwelche stack traces vom senden der Pakete?

[Ramkhamhaeng]

Hallo,

meine bisherigen Versuche haben noch keinen Erfolg gehabt. Ich will trotzdem kurz skizzieren, was ich gefunden habe. Auf dem Screenshot sieht man einen Mitschnitt durch das Programm "Api Monitor 2". (Den Mitschnitt lade ich gerade auf deinen Server unter /home/pb/ramk/goodCapture.apmx64 hoch)

Da ich nicht weiß, wonach ich genau suchen soll habe ich nach Funktionen gesucht, die was mit Timeouts zu tun haben könnnte. Gefunden habe ich Sleep() (klar ), GetTickCount() und WaitForSingleObject(...).

Es könnte sein, dass es noch andere gibt und meine Auswahl gar nicht geeignet ist, um die Stelle zu finden, wo das Senden des nächsten TCP-Paketes verzögert wird.
Oder meine Vermutung, dass die Übertragnugsgeschwindigkeit per Timeout gesteuert wird, ist falsch. Vielleicht kann man die Geschwindigkeit ja auch an die Lib weiter geben, die den Spielstand versendet?!



Nun zu dem Bild. Es sind zwei Threads am Versenden beteiligt: 1 und 6. Nach dem oberen sendto() wird viermal WaitForSingleObject mit 25ms Timeout aufgerufen. Danach wird das nächste Paket versendet.


Meine Idee war es dann diese 25ms zu manipulieren. Als erstes habe ich daher alle Vorkommen von 0x00000019 in der Exe ausgetauscht. Es waren 130 Vorkommen. Das Programm lief danach immer noch, aber ich habe dabei nicht die Stelle erwischt, die das Timeout vorgibt. (Verdammt, das wäre auch zu schön gewesen )

Nun gut, als nächstes habe ich das Programm "Winapioverride" gefunden. Damit kann man Api-Aufrufe wrappen, was ich für die obige Funktion tat. Aber egal, ob ich die 25ms in 7ms oder 250ms änderte.... An der Übertragungsgeschwindigkeit des Spielstandes hat sich nichts geändert :/


Was ich noch nicht getan habe ist zu schauen, ob sich die Anzahl der Aufrufe von WaitForSingleObject zwischen zwei sendto()-Calls verändert, wenn ich den Timer reduziere.
Ich würde jetzt vermuten, dass vielleicht eher mit GetTickCount() gewartet wird bis eine Differenz einen Schwellwert überschreitet

[Ramkhamhaeng]

Es könnte auch sein, dass die beiden Threads überhaupt nicht miteinander verzahnt sind. Dann legt sich Thread 1 nach dem sendto() schlafen, ruft GetTickCount auf und wacht 100ms später wieder auf. Bleibt die Frage mit wie er sich schlafen legt

[Zulan]

Ja ich versuch grad rauszufinden wie die Threads miteinander interagieren. Irgendwie werde ich aus dem API log nicht schlau :/. Also es sieht zwar so aus als ob die mit dem EnterCriticalSection kommunizieren, aber warum der Thread 1 das EnterCriticalSection so spaet aufruft und dann auch sofort dran kommt... da muss noch irgendein anderer Mechanismus sein.

Ich hab leider keine IDA Lizenz und der OllyDBG ist bei weitem nicht so schoen :-(.

Der unmittelbare send-Wrapper wird noch von anderen code-teilen aufgerufen und der Thread 6, der sich scheinbar um den lesenden socket kuemmert, laeuft auch irgendwie dauerhaft. Das macht das debuggen noch bisschen schwieriger...

[Ramkhamhaeng]

Die Filterung im API-Log ist etwas merkwürdig, ja. Ich habe jetzt doch noch einen anderen Aufruf von WaitForSingleObject in Thread 1 gefunden. (Mit 100ms Dauer, interessanterweise in python24.dll *). Wenn ich diesen auf 10ms reduziere sehe ich in Wireshark sogar schon eine Änderung bei den Zeiten: 80ms statt 100ms.
Warum 80?! Evtl. wartet Thread 1 irgendwie noch auf den Thread 6, wo die vier 25 ms Schritte ablaufen


(*) Wenn das in der python-DLL liegt könnten wir doch eigentlich sogar in den Code einsehen ?!

[Ramkhamhaeng]

Ich glaube wir sind der Lösung schon recht nahe. Nachdem ich die Timeouts von 100ms auf 10ms verringert hatte wird das Warten statt einmal ca. 8 mal vom Thread 1 ( Hauptthread) aufgerufen.
In diesem wird außerdem mit GetTickCount() die Anzahl der vergangenen Millisekunden verglichen.
Dieser Aufruf steht an Position 0x517C3F in Civ4BeyondSword_Pitboss.exe

Vielleicht gelingt es dir danach das If-Statement zu identifizieren, mit der die Zeitdifferenz verglichen wird. Ich habe gestern noch RecStudio installiert, aber die GUIs dieser Programme sind fast ein genauso großes Rätsel wie die zu analysierenden Bytes.

[Zulan]

Ich bin mir nicht sicher ob das so einfach ist. Ich koennte mir vorstellen, der Thread arbeitet irgendeine Queue ab, die von einem anderen Thread gefuettert wird. Das wuerde zumindest die Arbeit mit dem Mutex erklaeren... Nur wer fuettert die Queue?

Ich hab jetzt mit dem kostenlosen IDA 5 gearbeitet. Das ist an sich ganz gut aber die Thread-Anzeige ist ziemlich nutzlos.

[CocoRico]

Wird Zeit, dass es für Informatiker auch einen Nobelpreis gibt ...

[rucivfan]

Dafür gibt es den Turing Award. Das Kernproblem beim Nobelpreis dürfte wohl sein, dass es Informatik zu Zeiten Nobels nicht als eigenes Fachgebiet gab.