Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Start Server-Spiel auf Client bricht ab
#1
Hallo!

Ich habe mir Simutrans für meinen gehosteten Server compiliert und mit kleineren Karten startet auch ein Client tadellos. Nun möchte ich mit meinen Kindern aber auf einer sehr großen Karte spielen. Habe mir dazu Deutschland zusammengebaut mit knapp 3800x4700 Feldern. Das ist recht groß, aber vom 32-Bit Simutrans noch beherrschbar. Beim Spielstart reagiert aber der Server offenbar zu langsam, da er erst anfängt, den Spielstand zu sichern. Zumindest meine Vermutung. Trotz 4 Intel-Kerne E5 und SSD-Festplatte quittiert der Client nach einem Weilchen mit "Protocol Error (expected NWC_GAME)".

Falls tatsächlich der Server hier etwas zu langsam: Wie bekomme ich den Client dazu, länger zu warten? Da ich nun den Server schon compiliert habe, würde ich u.U. zur Behebung des Problems auch den Client neu compilieren. Aber wo stellt man den Timeout ein? Falls es überhaupt ein Timeout-Problem ist.

Viele Grüße
Frank
Zitieren
#2
Nein: Der Server stürzt ab. Das scheint der Grund zu sein. Aber warum? Unter Windows lief es im Heimnetzwerk schon.
Zitieren
#3
Möglichkeit 1 (wenn es ein Vserver ist): Schlicht nicht genug Speicherplatz.

Was man eh probieren sollte: bzip2 ist speicherhungrig. Versuch es mal mit der zip-Komprimierung, die ist viel schneller und nur unwesentlich größer. Das würde auch evt. Timeoutprobleme lösen.

Es besteht aber durchuas die Möglichkeit, dass der Server nicht dieser Monsterkarte gewachsen ist. Auf meinem Rechner mit Athlon 6000+ (immerhin sehr gute Singlethread Performance) mit 4GB Speicher braucht es allein zum Erstellen einer leeren Karte dieser Größe >30 Minuten. Server sind ja mehr für eher für Preis und Verbrauch optimiert, da meist eh die Netzverbindung das Limit ist, so dass gute Chancen bestehen, dass die Karte nicht einmal geladen wird, bzw. dann auch in Echtzeit ausgeführt werden kann.

Für Netzwerkspiele mit solchen Karten sollte -fps auf 10 oder kleiner gesetzt werden.
Zitieren
#4
Hallo Prissi!

Danke für die Antwort. Smile

Ich hab jetzt zuerst mal auf xml_zipped umgestellt. Was allerdings nicht geholfen hat. :evil: Dann habe ich binary verwendet: Und es geht! Big Grin *hopps*spring*hüpf* 8) Ziemlich fix nach dem Verbindungsaufbau beginnt der Kartendownload. Dank knapp 6 GByte RAM, was Linux für Filecache zur Verfügung bleibt und natürlich der SSD und den 4 Kernen des E5-Prozessors (so schlecht scheint die aktuelle 15-Euro-NetCup-Hardware nicht zu sein ^^ ).

Nach 17 Sekunden beginnt der Download. Die Filegröße der Karte ist jetzt unkomprimiert 271MByte. Es scheint aber einen echten Bug zu geben:

Fehlerforschung Rolleyes

Es gibt 2 Schwachstellen:

1) Mit Zip/bzip2: Der Abbruch des Clients scheint ganz klar ein Timeout zu sein: Nach genau 120s kommt die Fehlermeldung. Abhilfevorschlag: a) Timeout vergrößern. b) Das Timeout mit in die Clientkonfigurations-tab legen. c) Meiner Meinung nach beste aber aufwändigste Lösung: Server sendet einen Fortschrittswert an den Client, solange der Kartendownload noch nicht bereit ist. Und der Nutzer am Client bekommt einen Abbruch-Button über diese Zeit angeboten.

1a) Bei meiner Karte dauert das Zippen offenbar um die 2 1/2 Minuten oder länger. Vielleicht kann "man" (also die Entwickler) eine geringere Kompressionsrate als Standart wählen.



Weiterhin hab ich an einer funktionierenden Client-Server-Konfiguration getestet. Ausgangspunkt: Nutzer startet das Onlinespiel, was den Server zuerst veranlasst, das aktuelle Spiel zu sichern. Unterbricht man in diese Zeit den Client...:

2) Wenn der Client geschlossen wird, während der Server das Savegame speichert, um dann dem Client die Karte zu senden: stoppt oder crasht der Server!

Der Punkt 2) überrascht mich. Das müsste den Betreibern von öffentlichen Spieleservern mit Simutrans aufgefallen sein: Entscheidet sich der Nutzer beim Verbinden, doch nicht zu spielen und bricht Simutrans ab, müsste jeweils die Serverapplikation stoppen/crashen. Da kann man zwar ein Workaround für schaffen, aber Spieler die schon online sind, werden abgewürgt.

Wichtigkeit:

1) "Nice to have"
2) Wichtig für Server-Betreiber


Jedenfalls erklären beide Punkte in Summe das von mir oben beschriebene (Gesamt)verhalten mit meiner großen Karte. Die Kartengröße selbst ist also nur der Auslöser.

Viele Grüße
Frank
Zitieren
#5
Das Timeout (zumindest bein Windows) steckt im Betriebssystem und war lange Zeit bei 60s. (Ich glaube, das liess sich in der Regestry (wie heisst das auf Deutsch?) einstellen.

xml is für solche Riesenkarten unbrauchbar, das das ganze unkomprimiert sicher größer als 16 GB oder so wird, Alllein diese MEnge an Daten zu generieren dauert ewig, vom Verarbeiten ganz zu schweigen. Zip ist schon schnell, und das packen mit Multithreading is gerade so schnell, wie überhaupt die Daten erzeugt werden (so denn mehr als ein Kern zum Server gehört).

Eine Karte mit 270 MB ist schon mehr als Grenzwertig, finde ich. Zumal jedes Mal, wenn noch jamand dazukommt, der lokale Client auch die Karte speichern und laden muss. Wenn der neue Client dann nicht ganz so potent ist, gibts Verbindungsabbrüche am laufenden Meter. (Mal abgesehen, dass selbst mit einer 16 MBit ADSL+-Leitung das ganz ca. 4 Minuten dauert).

Das mit dem Abbrechen ist mir lokal bei Testen jedenfalls nicht aufgefallen.
Zitieren
#6
Also ich komme rechnerisch bei einer 270MByte-Karte bei 16 MBit/s auf 140 Sekunden. Also samt vorherigem Abspeichern der Karte auf dem Server dauert es etwas mehr als 2 1/2 Minuten, bis die Karte in den eigenen Speicher geladen wird. Hab es auch gerade nachgemessen. Kommt in etwa so hin: 75 Sekunden Übertragungszeit bei ca. 30 MBit/s.

Wenn nun die Komprimierung nicht fehschlagen würde, bei der die Karte dann nur noch 60 MByte groß wäre (so groß ist zumindest das sve-File), würde es mit 16Mbit/s nur noch eine halbe Minute benötigen. Und bei meiner Internetverbindung 10...15 Sekunden. Allerdings kommt dann die Komprimierungszeit auf dem Server dazu.

Also ich finde, das ist noch im Rahmen, wenn man dann 1...2 Stunden spielt. Vor allem, wenn man realistische Zuglängen, Güterbahnhofsgrößen und Fahrzeiten haben möchte und über mehrere Dekaden mit der langsamsten Simulationsgeschwindigkeit spielen möchte. Mein bisheriges Spiel war mehr als halb so groß und ich habe allein drauf gespielt. Da hat man schon ordentlich zu tun. Aber wenn dann drei auf einer Karte spielen, drittelt sich das.

Timeout: Ich entwickle beruflich selbst Software. Für TCP-Verbindungen gibt Windows keinerlei grundsätzliche Timeouts vor, da der TCP-Server bzw- Client an einem Port immer von der Applikation implementiert wird und nicht von Windows. Windows übernimmt nur die Pufferung und Zuordnung zum TCP-Server/Client der Applikation über die Portnummer, um das Datenpaket entsprechend zu übergeben. Ab wann eine TCP-Verbindung den Partner nicht mehr als "Online" erkennen möchte, ist Applikationssache. Kann natürlich sein, das hier Bibliotheken verwendet werden, die unter Standardbedingungen eine Verbindung nach 120s als Timeout killen. Aber das läst sich ganz bestimmt ändern. Vor allem sollte dann der Simutrans-Server nicht sterben, wenn der Client nicht mehr empfangen will. Senderseitig könnte da vielleicht ein FIFO (Sendepuffer) sein, dessen Vollaufen nicht abgefangen wird.

Ich möcht da auch nicht rummeckern. Das Problem ist ja eher ein Ausnahmefall. Und selbst den Quellcode durchzugehen, hab ich auch keine Lust.

Jetzt wird erst mal gespielt. :-)

Viele Grüße!
Zitieren
#7
ADSL 16 Mbit nominell sind bei mir 10 MBit netto oder knapp 1.2 MB/s. Da sollte ziemlich genau 220 Sekunden dauern. Ich hatte noch nie ADSL wo da ankam, was zuerst versprochen würde.

Zip sollte nicht länger dauern als binary, da der Zip-Algorithmus heutzutage fast schneller ist als manche Massenspeicher. Zumindest wenn du mehr als einen Kern hast (was bei einem Vserver nicht der Fall sein mag). bzip2 ist ca. 10x aufwendiger, und daher langsam.

Vielleicht ist das Problem eher, dass ein zweiter Thread aufgemacht wird, der dann aus irgendwelchen Gruenden scheitert. Dass könnte man beheben, indem man den Server explizit ohne "MULTI_THREAD" compiliert.

Timeout: Sorry, ich hatte das mit dem 30s open_socket timeout auf nicht-exitierende Adressen verwechselt. In der Transferroutine selbst ist ein 10s timeout. D.h. sobald der Server loslegt, sollten mindestens 4k daten in 10s eintreffen, sonst gibt es einen Timeout. Der Knackpunkt steckt in "nwc = network_check_activity( NULL, 60000 );" in der Datei network_file_transfer.cc in Zeile 205. Der Server hat ein sync-Kommando gesendet, aber noch keine Daten. Ich werde den Wert höher setzen und den Ladebalken mit "Server preparing game" oder so melden lassen.

Ich werde mal weiter testen, die Hinweise waren recht hilfreich zur Fehlersuche.

EDIT: Ich konnte aber in keinem Falle der Server selbst zum crashen bringen, egal wannich abbrach.
Zitieren
#8
@prissi: der Ladebalken wird aber gar nicht aktualisiert. Nun wartet das Programm nur laenger. Man koennte doch die for-Schleife x-mal warten lassen, und jedesmal den Balken vorruecken.
Zitieren
#9
Im Ladebalken sollte der neue Text stehen ... trotzdem, gute Idee.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste