Server disqualifiziert Clients wegen Soft-Timeout obwohl Zug rechtzeitig gesendet wird

Wir hatten ja schon immer das Problem, dass es vorkommen kann, dass der Server durch den Garbage Collector in dem Moment angehalten wird, wo ein Client einen Zug sendet, und dass es auch schon sehr nah an dem Soft Timeout (2s) dran ist. Wenn der Server dann erst nach den 2s wieder weiterlaufen kann, weil der GC Lauf einige hundert ms gedauert hat (was durchaus vorkommen kann), wird der Client disqualifiziert, obwohl er den Zug rechtzeitig sendet.

Das haben wir diese Saison recht gut im Griff, durch optimierung der Startparameter des Servers (habe ich hier gestern auch nochmal dokumentiert: https://cau-kiel-tech-inf.github.io/socha-enduser-docs/#soft-timeouts).

Leider tritt dieses Problem bei langen Testlaeufen der Schueler wohl noch auf, auch wenn sie die Parameter verwenden. Das ist nicht verwunderlich, weil das ein anderes Szenario ist, als das unseres Wettkampfservers.

Nun gibt es aber noch eine Moeglichkeit, das in den Griff zu bekommen. Mit System.gc() kann man dem GC den Hinweis geben, dass jetzt ein guter Zeitpunkt waere, einen GC Lauf zu machen. Wenn man das direkt nach der Zuganforderung im Server einbaut, koennte das Problem verschwinden. Das eigentlich aufwaendige dabei ist, zu testen ob das wirklich funktioniert. Du muesstest also erstmal das Problem messbar nachstellen, dann System.gc() einbauen und nochmal messen.

Aber du brauchst einen client der die genaue zeit misst, die er braucht und am besten auch nahe am soft timeout operiert. Diese zeiten vergleichst du dann mit den zeiten, die der server misst. Bei grossen unterschieden (>100ms) hast du das GC problem.

Dann kannst du noch die GC Lauefe loggen, das geht ueber parameter die ich in dem oben verlinkten artikel auch mit drin habe.

Dann baust du das System.gc() ein und guckst, ob das Problem nicht mehr auftritt. Dabei immer im rahmen von automatisierten testdurchlaeufen mit dem non-gui-server testen. Brauchst also noch ein kleines script, was den client immer zweimal startet. Und wenn die clients sich beenden direkt nochmal fuer das naechste testspiel, das ein paar hundert mal.

Start with the server's soft-timeout handling and the non-GUI server test setup, then create the mentioned client timing and repeated-game script. Reproduce and measure differences between client and server timings near the two-second timeout, with GC logging enabled. Add System.gc() after move requests and compare automated runs; done means the discrepancy and resulting disqualifications no longer occur.