Serverprobleme
Aus LM Wettbewerb
Vom 8. bis 25. August lief ein in Perl implementierter singledthredded Server bis zur Version 0.6. Am 25. August 2010 kommt ab 18 Uhr der Diceordie Server zunächst in der Version 0.3.2-rc1 zum Einsatz. Falls es Probleme gibt, bitte hier melden.
-- Magnus 17:48, 25. Aug. 2010 (CEST)
Inhaltsverzeichnis |
[Bearbeiten] Neu in 0.3.2-rc4: Zeilenterminatoren
Weil sich Magnus sicher bald in das Wochenende verabschiedet, habe ich in aller Eile noch Version 0.3.2-rc4 hinterhergeschoben:
- DENY-Meldungen an beide Parteien für alle möglichen Spielabbrüche
- Eine echt tolle Sache, finde ich... da ist so ein Bot/Mensch mit der IP 87.180.xxx.xxx, der für massenhafte Timeouts sorgt. --93.204.166.148 20:26, 27. Aug. 2010 (CEST)
- Neue Empfangsroutine (getestet mit '\n', '\r', '\r\n' und '\n\r' (wer weiss..))
- Vor Spielstart bekommen die Spieler einen Teil ihrer IP als Spielernamen, damit eine glaubwürdige Fehlermeldung generiert werden kann, wenn sich ein Spieler vor dem AUTH verabschiedet.
- ERRORS und TIMEOUT mit korrekter Fehlersumme (0 oder 1, weil der Server immer beim ersten Fehler abbricht) für die Statistik-Auswertung.
- Regelkonformer Versionsstring
--Solarix 09:22, 28. Aug. 2010 (CEST)
Magnus und ich hätten sicher nichts dagegen, wenn jemand lokal bei sich ein paar Fälle (sowohl fehlerhafte wie auch korrekte Sessions) testen würde und sein OK hier geben könnte.
--Solarix 09:37, 27. Aug. 2010 (CEST)
[Bearbeiten] Frage zum Serverstart
Ich muss den Server mit
./dodservergui 0.0.0.0 3333 >> LOGS/log-0.7.txt &
starten, das ist doch richtig, oder? Mit localhost konnte ich den Server nur über das lo-Interface erreichen, über wettbewerb... erhielt ich einen Assert-Fehler:
ASSERT: "serverReady" in file dodservice.cc, line 61 Aborted
-- Magnus 18:33, 25. Aug. 2010 (CEST)
Ja, das ist korrekt so.. ich gebe bei rc2 nun immerhin die Fehlermeldung des System weiter und schmeisse keinen ASSERT mehr. Das Ergebnis bleibt gleich, aber es sieht etwas eleganter aus.
--Solarix 19:39, 25. Aug. 2010 (CEST)
Solarix, der Server läuft richtig gut - und ca. 10x schneller als die vorherige Version. Schon jetzt ein dickes Lob dafür.
--Toralf Wed Aug 25 20:42:23 CEST 2010
[Bearbeiten] Zum DoDS 0.3.2-rc3
Authentifikation klappt besser: Scheinbar kommen nun deutlich mehr Bots mit der DoDS 0.3.2-rc3 zurecht. Probleme haben immer noch daschatten in den Version 11 und 14, sowie MegaDiceCubeDing. Ganz selten auch noch ein paar andere.
- Ich werde da nochmals eine Änderung einbauen und mindestens beiden Teilnehmer mitteilen, weshalb die Verbindung gekappt wird ("z.B. "DENY Spieler XY hat unverständliches Kommando gesendet: ....").
Parallele Bots: Die Zahl der aktiven Sessions bleibt fast immer unter 10, liegt das an der Netzlatenz? Ich sehe keine großen Unterschied mit und ohne Nagle-Algorithmus. Vielleicht egalisiert sich der Effekt, wenn die Clients tatsächlich übers Netz mit der entsprechenden Latenz kommen? Real finden pro Minute rund 110 Spiele statt.
- Das dachte ich mir schon. Je besser der Ping zwischen Client und Server ist desto mehr beschleunigt das Ausschalten des Nagle-Algos. Ich habe es nie ausprobiert, aber ich bin überzeugt, dass ein Client bei Verbindungen via Internet keine 100%-Last auf dem Server erzeugen kann weil die I/O-Zeiten einfach zu lang sind.
Protokoll-Konformität: Tatsächlich wäre eine Versionsnummer wie "0.3.2-r3", die gerade läuft, nicht Protokollkonform. Daher werde ich zukünftig jeweils dodconfig.h dahingehend patchen, dass als Welcome-String dort "0.8 based on DoDS 0.3.2-rc3" erscheint. Damit behalte ich die Serverversionierung weiter bei, verweise aber trotzdem auf die tatsächlich laufende Instanz.
- Ich passe das gerne in dodconfig.h an (von "0.3.2-rc3" in "0.3 (0.3.2-rc3)" oder so..)
Abbrüche, Errors: Wenn ein Client abbricht oder nicht vollständig authenfiziert werden konnte o. ä. meldet der Server gegenwärtig als Spielergebnis "REGULAR", sollte jedoch "ERRORS" lauten. Lässt sich das einfach nachrüsten? Die Statistik hat nämlich als Assert eingebaut, dass bei "REGULAR" mindestens einer der erzielten Punktwerte 50 betragen sollte. Außerdem vermeldet der Server manchmal die Spielernamen als "???", dann gibt's allerdings immer korrekt ein "TIMEOUT", wie ich sehe.
- Selbstverständlich... Ich möchte in rc4 auch noch ein paar DENY-Meldungen einbauen..
GUI-Tabelle: Eher eine Kleinigkeit: Die Werte der Tabelle sind offenbar alphabetisch sortiert, nicht numerisch, denn ein Bot mit "100.00" Prozent erscheint fast ganz am Ende der Tabelle, direkt über denen mit 9% und unterhalb von 11%.
- Dahinter steckt Absicht, weil sich die Spalten auf Klick sortieren lassen. Es wird zwar hinterher nicht in Echtzeit sortiert (ein guter Spieler wandert nicht automatisch nach oben), aber ich dachte die Sortierung auf Klick genügt in der Praxis.
Stresstest: Ich habe eben einmal so viele Bots der tux-Familie gestartet, wie mein Shellscript/nc-Wrapper parallel zu starten imstande war. Das hat die Zahl der Sessions auf gut 80 hochgeschraubt. Dann stürzte der Server jedoch nach einigen Minuten mit
$ ./dodservergui 0.0.0.0 3333 >> LOGS/log-0.8a.txt
GLib-ERROR **: Cannot create pipe main loop wake-up: Too many open files aborting... Aborted
an. Woran kann das liegen?
-- Magnus 16:31, 26. Aug. 2010 (CEST)
Ist mir eben auch noch einmal ohne die Tuxe passiert.
-- Magnus 16:34, 26. Aug. 2010 (CEST)
Das ist ja spannend.. ich versuche das noch zu reproduzieren!
--Solarix 18:27, 26. Aug. 2010 (CEST)
Und ich dachte schon das liegt an meinem Bot ;) Kannst du rausfinden, welche Bots konform laufen und welche nicht?
In meinem Fall wäre das wutzara. Spielen funktioniert aber ab und zu bekomm ich einen Timeout (habe meinen Timer jetzt auf 3 sek gestellt). Würd mich halt interessieren an was das liegt und ob ich sauber getrennt werde.
Dieser Fehler passiert, wenn ein Prozess zu viele Dateien (Pipes, Sockets) gleichzeitig geöffnet hat. Dieser Wert wird vom Betriebssystem begrenzt und kann mit "ulimit -a" angezeigt bzw. geändert werden. Es sind zwei Ursachen dafür möglich, entweder sind zu viele Clients gleichzeitig verbunden, oder File-Deskriptoren werden nicht richtig aufgeräumt. Die geöffneten Dateien kann man übrigens mit dem Befehl "lsof" anzeigen.
Noch eine kleine Warnung, bevor versucht wird den Wert zu erhöhen. Einige System-Calls (z.B. select()) arbeiten nicht richtig mit File-Deskriptoren ab 1024. Außerdem könnte man in ein weiteres Problem hineinlaufen, wenn pro Client ein Thread gestartet wird. Dann könnte nämlich auf 32-bit Systemen der Adressraum ziemlich schnell ausgehen.
--Sleafar 19:54, 26. Aug. 2010 (CEST)
Ist dieser Server tatsächlich schon wettbewerbstauglich? Ich habe wiederholt erlebt, dass die Verbindung zum Server einfach mitten im Spiel beendet wurde. Mal angenommen, dies könnte durch ein gezieltes Fehlverhalten des anderen Client ausgelöst werden, dann wäre das eine riesengroße Einladung zum Schummeln. Wenn es schlecht steht, einfach den Fehler auslösen... Ich erwarte in jeder durch den einen Client verursachten Fehlersituation, dass dies als Sieg für den anderen Client gewertet wird und dass dies auch protokoll-konform übermittelt wird.
--Jodado 21:49, 26. Aug. 2010 (CEST)
[Bearbeiten] Überraschende DENYs
Ich sehe inzwischen öfter Meldungen wie diese:
<-- THRW 6 hat Spieler 1 (wubbel) gewuerfelt <-- DENY Fehler durch Spieler GANNbot_evon_train_9_6: Timeout
Wie reagiere ich darauf korrekt? Wenn ich einfach nichts mache dann passiert länger nichts und nach 60s schießt sich mein Bot via Time-Out selber ab. Sollte nicht der Server nach einer DENY-Nachricht die Verbindung schließen? --Nomeata 23:05, 28. Aug. 2010 (CEST)
Wenn ich die Protokollbeschreibung richtig interpretiere, sollte hier eigentlich WIN statt DENY kommen. DENY sollte nur als Antwort auf AUTH kommen, d.h. bevor das Spiel beginnt.
--Sleafar 9:00, 29. Aug. 2010 (CEST)
Sehe ich zwar auch so, aber würde bei einer Änderung das Ergebnis stark verfälschen.
--85.176.137.141 08:08, 29. Aug. 2010 (CEST)
Wer auch immer der "Herr der GANNbot_evon_train_*" sein mag... Bei 1000 Spielen immer 5 Sekunden warten zu müssen fällt ganz ordentlich ins Gewicht. Wenn Du schon den Server mit 20 verschiedenen Bots fluten musst, dann fixe doch bitte wenigstens die Timeouts ;-)
Was die DENYs angeht hoffe ich, das wird im Turnier noch geändert :-)
--diceEater 12:34, 29. Aug. 2010 (CEST)
Wo ist das Problem mit DENY ? .. DENY ist ne Fehlermeldung.. nach der Meldung ist alles TOT .. also mach ich einfach einen reconnect(oder beende den bot) >.> Selbst nach eine WIN/DEF reconnect ich(oder beende den bot) .. keine ahnung ob mich der Server vorher rausschmeißt .. ist mir auch wurscht .. nach WIN/DEF/DENY ist alles aus..
--KoKuToru 12:57, 29. Aug. 2010 (CEST)
@diceEater: Sorry fuer die Unannehmlichkeiten. Hab die Bots zwischenzeitlich ausgeschaltet, um dem Problem mit den Timeouts auf den Grund zu gehen. Es scheint, dass die Timeouts zustande kommen, wenn der Server zweimal 6 in Folge wirft, z.B so:
TURN 11 18 Du bist dran! ROLL (from GANNbot_evon_train_12_3) THRW 6 hat Spieler 2 (GANNbot_evon_train_12_3) gewuerfelt THRW 6 hat Spieler 1 (Landliebe) gewuerfelt TURN 0 18 Du bist dran! ROLL (from GANNbot_evon_train_12_3) GANNbot.cpp:643: Timeout or Error. GANNbot.cpp:644: Error type: QAbstractSocket::RemoteHostClosedError
Also, GANNbot macht ein ROLL und direkt danach folgt RemoteHostClosedError. Muss mal debuggen.
Kann jemand sagen, ob er das Timeout-Problem bei 2 aufeinanderfolgenden 6 auch gesehen hat? Sind 20 gleichzeitig laufendene Bots zu viel fuer den Server?
@Nomeata: welche Zahl wurde geworfen vor der 6?
Gladnon 13:33, 29. Aug. 2010 (CEST)
Topic "Client hat Timeout nach DENY": Der Server beendet in jedem Fall die Verbindung. Daher einfach wie KoKuToru geschrieben hat vorgehen.
Topic: "WIN anstelle DENY": Diese Feststellung ist korrekt: das Verhalten des Server weicht hier vom LM-Artikel ab. Ich bin jedoch der gleichen Meinung wie 85.176.137.141: Das würde momentan nur die Statistik verfälschen. Ob der Server nun ein WIN oder ein DENY sendet spielt für den Wettbewerb IMHO keine Rolle, weil der Serverlog eine solche Auswertung schon jetzt zulässt...
Topic: "Crash nach 2x6": Halte ich eher für unwahrscheinlich, weil dieser Fall recht oft vorkommt. Ich glaube eher, dass dies einfach das "GLib-ERROR"-Problem (s. weiter oben) aus Sicht eines Clients ist. Dies wird mit v0.4 behoben.
--Solarix 14:18, 29. Aug. 2010 (CEST)
[Bearbeiten] Man kommt nicht mal dran
Ich komme nicht dran ob wohl ich dran bin..
TURN 13 31 Du bist dran! THRW 2 hat Spieler 1 (KoKuToru_ReTrain) gewuerfelt TURN 15 31 Du bist dran! THRW 2 hat Spieler 2 (meh) gewuerfelt THRW 4 hat Spieler 2 (meh) gewuerfelt THRW 4 hat Spieler 2 (meh) gewuerfelt TURN 15 41 Du bist dran! THRW 2 hat Spieler 2 (meh) gewuerfelt THRW 4 hat Spieler 2 (meh) gewuerfelt THRW 1 hat Spieler 2 (meh) gewuerfelt TURN 15 48 Du bist dran! THRW 4 hat Spieler 2 (meh) gewuerfelt
--KoKuToru 22:54, 29. Aug. 2010 (CEST)
Hm, dieses Beispiel verstehe ich nicht. Was hast Du denn versendet? -- Magnus 03:04, 30. Aug. 2010 (CEST)
- Okay man das ist jetzt aber echt gay .. man darf SAVE machen wenn man 0-Punkte hat ? haben wir kein min. 1 mal ROLL pflicht ?! Wenn der gegner ein SAVE macht ohne je irgendwann mal gewürfelt zu haben .. kommt mein ganzer BOT durcheinander und weiß nicht mehr wer dran ist !! Und sendet dadurch SAVES .. so yaaa jeder weiß jetzt wie er meinen bot killen kann .. warten bis ich SAVE machen.. dann muss du nur ein SAVE machen .. und mein Bot wird bis zum Spielende nur mehr SAVE machen.. Keh sprich ich muss was umschreiben damit er besser erkennt ob er "nochmal" dran ist.. --KoKuToru 23:35, 29. Aug. 2010 (CEST)
Wieso auch nicht? Wenn mein Bot weiss, dass er gleich sowieso eine 6 würfelt, darf er doch einfach saven, selbst wenn er keine Punkte hat. ;-) Ich könnte mir z.B. einen Bot vorstellen, der den ersten Zug nicht macht, weil er noch nichts über den Gegner kennt. Und ja, das ist natürlich sinnlos, aber wieso nicht? -- Balu 01:17, 30. Aug. 2010 (CEST)
- Jo und wenn 2 bots da sind die das wissen.. dann wird das Spiel nie fertig werden..--KoKuToru 10:55, 1. Sep. 2010 (CEST)
Diese Diskussion hatten wir doch schonmal. Spieltechnisch ist es ziemlich sinnlos, als erstes eines Turns gleich zu sichern (genaugenommen absolut sinnlos). Ich hatte das auch in einer frühen Version des Artikels stehen, hab das aber wohl aus Verständlichkeitsgründen wieder entfernt. Ich tendiere weiterhin dazu mindestens einen Wurf verbindlich zu machen, aber ich will auch nicht, dass dadurch Bots nicht mehr funktionieren. Ich würde also Einsender, die daran scheitern, einmalig die Möglichkeit geben, nachzubessern. Solarix, kannst Du das einbauen oder soll ich mir mal den Code dazu ansehen? Achja, ich wollte immer auch noch einen Art Sanity-Check bei den Botnamen einführen, gibt's in Qt eine einfache RE-Klasse oder sowas ähnliches?
-- Magnus 03:04, 30. Aug. 2010 (CEST)
".. kommt mein ganzer BOT durcheinander und weiß nicht mehr wer dran ist !!"
Ein Spieler kommt genau dann dran, wenn der Server TURN sendet. Dabei spielt es ja keine Rolle, ob der Gegner wegen einer 6 zur Abgabe gezwungen wurde, oder mit SAVE freiwillig abgegeben hat. Evt. sollte ich wohl noch eine Prüfung einbauen, ob ein Spieler schon vor TURN eine Antwort gesendet hat und dies als Fehler werten....?
- Mein Bot wartet auf den ersten Wurf des Gegners .. damit er erkennt ob SAVE die richtig Entscheidung .. oder die falsche war, wie auch immer mein Code ist schon umgeschrieben und es sollte jetzt egal sein ob der Gegner würfelt oder nicht..--KoKuToru 10:55, 1. Sep. 2010 (CEST)
"Mindestens 1 ROLL.. Solarix, kannst Du das einbauen oder soll ich mir mal den Code dazu ansehen?"
Das ist kein grosses Problem... evt. könnte ich das auch wählbar einbauen.. deine Version des Servers hat IMHO dann nochmals ein TURN gesendet. Das hat mir damals nicht so gefallen, weil fehlerhafte Bots dadurch eine Partie lahmlegen konnten (Always SAVE). Soll das so bleiben, oder soll mit einem Fehler abgebrochen werden?
"Achja, ich wollte immer auch noch einen Art Sanity-Check bei den Botnamen einführen, gibt's in Qt eine einfache RE-Klasse oder sowas ähnliches"
Klar... ich könnte noch einen Check einbauen und bei fehlerhaften Botbezeichnungen ein DENY + Grund senden...
Hast du (Magnus) in diesem Chaosartikel den Hinweis zu v0.4 gesehen?
--83.97.83.133 08:54, 30. Aug. 2010 (CEST)
[Bearbeiten] Warning: ::waitForBytesWritten()
Nachdem der Server 0.4.0/0.10 nun seit rund zwei Tagen gut läuft, hat er irgendwann zwischenzeitlich viermal folgende Meldung gespuckt:
QAbstractSocket::waitForBytesWritten() is not allowed in UnconnectedState
Ich beobachte aber keine Probleme im Ablauf.
-- Magnus 10:27, 1. Sep. 2010 (CEST)
Das konnte ich lokal auch schon beobachten. Da versucht der Server eine DENY-Meldung an einen Client abzusetzen, welcher sich bereits disconnected hat (was evt. ja auch der Grund für die DENY-Meldung ist). Das hat jedoch -wie du bereits beobachtet hast- keine Auswirkung auf den Betrieb. Ab v0.5 ist das behoben.
--Solarix 10:34, 1. Sep. 2010 (CEST)
[Bearbeiten] Turniermodus
Hallo Solarix, hast Du Lust, mir mal eine Nachricht per E-Mail zu schicken? Ich überlege noch, wie den Server für das Turnier am besten aufsetze. Meine Kontaktdaten stehen auf meiner Benutzerseite.
-- Magnus 17:29, 1. Sep. 2010 (CEST)
Kannst du bestätigen, dass du die Mail bekommen hast? Ich habe bisher keine Antwort erhalten und möchte nur bestätigt haben, dass die Mail nicht in einem Spamfilter oder so hängen geblieben ist...
--Solarix 21:19, 2. Sep. 2010 (CEST)
[Bearbeiten] Störungen durch 91.214.xxx.xxx
Ich versuche gerade zu spielen, und erhalte ab und zu die Fehlermeldung:
DENY Server is full!
Der absolute Topreiter ist allerdings das folgende:
DENY Fehler durch Spieler 91.214.xxx.xxx: Kommando unbekannt
Ich habe den Eindruck, dass der Server gerade zugespammt wird, da das mit Abstand das häufigste Spielende ist. Vielleicht könnte ja derjenige mal seine Bots fixen.
- Das kann nur reine Absicht sein, wem würde es nicht auffallen das der Bot kein vernünftiges Spiel zustande bekommt? Oder versucht da einer mit Bruteforce und langen Strings Herr über den Server zu werden und sich eine remote shell zu besorgen. Mir ist das jedenfalls unerklärlich, es sind nicht nur die häufigsten Fehlermeldungen in meinem Log, es ist auch der Spieler den ich am häufigsten zugewiesen bekomme.--Soloko 22:31, 5. Sep. 2010 (CEST)
- Der Meinung bin ich auch. Kein ernsthafter Entwickler würde mit einem fehlerhaften Bot so oft (parallel) verbinden.--Solarix 22:54, 5. Sep. 2010 (CEST)
- Der ist ja immer noch da. --Sleafar 19:40, 6. Sep. 2010 (CEST)
- Wäre es nicht besser die Paarungen für das Training erst nach dem AUTH statt schon beim CONNECT festzulegen? --Sleafar 22:41, 5. Sep. 2010 (CEST)
- Das habe ich mir auch schon gedacht.. allerdings nicht wegen den aktuellen Störungen (die könnten -falls sie Absicht sind- damit nicht verhindert werden), sondern um gleich von Anfang an beiden Spielern den Namen des anderen mitteilen zu können. --Solarix 22:54, 5. Sep. 2010 (CEST)
Außerdem erhalte ich auch:
DENY Fehler durch Spieler ...: Timeout
Das kann ich mir gar nicht erklären, da mein Bot lediglich einen Tabellen-Lookup macht.
--Sleafar 22:20, 5. Sep. 2010 (CEST)
