Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Clients keep disconnecting

Started by WillysMD, January 06, 2016, 06:37:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.



I'm trying to setup a server to play with a few friends on a VPS.
The server seems to work properly. Clients can connect but they losse sync after a few seconds.
I've tried a few different settings without any improvement.
My ping on the server is around 90 ms, but another client with about 40 ms was disconnected all the same.

What settings are usual for server_frames_ahead, server_frames_per_step, server_frames_between_checks and additional_client_frames_behind?


Make sure all clients are the same versions.

Is the internet connection reliable? Simutrans does not do well if the server or client have unreliable latency (eg from a wireless network).


I compiled both clients and the server myself from the latest Github sources.
The server is located in France but I'm in Montreal, so I've got a bit of ping but it's very stable.
I've tried with a client in France with a better ping, but I had exactly the same result.

Maybe as you pointed out it's not latency related, so I'll check that by running the same server and client my computer.

PS: I used to play on a local gigabit network and still I had losses of sync. Not as often, but like every 5 minutes one of the 3 clients was loosing sync. It didn't bother me too much so I didn't do anything at the time.


There are issues with the netcode. Specifically "send to depot" is notorious for causing out of sync problems. That said many of the issues should have been fixed.


Stable ping is very important. 0% packet loss even more so.

If you run your Simutrans client with "-debug 3"  you can watch the timing in the messages printed in the console.
NWC_CHECK:     time difference to server 0

It can bounce around a bit, but should mostly track 0. When -'ve, if a command comes in from a player, you're at risk of a desync.
A desync because of this will show up as :
network_world_command_t::execute  wanted to execute(%d) in the past

Another type of desync is due to program bugs:
karte_t:::do_network_world_command", "disconnecting due to checklist mismatch"
Note: there are some bugs in 120.1.1 that will cause this. Some are fixed with 120.1.2, which if you're running a private server on self compiled is safe to use. Just the attempted official release went wrong...

Finally you may see:
network_receive_data", "connection [%d] already closed"
which is generally due to server issues, or network connectivity being lost.

If your self compiled versions don't/can't support the console display, you can add "-log" to the command, but then you have to search simu.log file rather than seeing the messages realtime.

120.1.2 also contains some tweaks to the network client timing that were developed/tested with a very badly overloaded Simutrans Experimental server game last year. That was running on a poor VPS as well - generally not good due to bursty nature of Simutrans CPU usage... Simutrans is very intolerant of the server lagging at all. Again 120.1.2 has improvements for that, and will spit out a log message: (older versions do not contain this message)
karte_t::interactive", "server lagging by %lli"
If you see that in your server logs, it's not cutting it CPU wise.

To answer your original question, the values for those parameters depend on the framerate you've set the server to run at.
The earliest servers were choked back to 10fps, but I find that makes the UI too sluggish. I've been testing a server running 20 for a while now and it seems ok with:
server_frames_ahead = 4 (default)
server_frames_per_step = 4 (default)
server_frames_between_checks = 200  (aiming for 10 secs based on 20 fps)
additional_client_frames_behind = x  - this must be set by each client based on the quality of their connection. I usually run 4 ok. Unless it's a transatlantic server, then those links tend to be very congested / jittery. even then 8, or 10 and I see desycs.


Thanks for all your insight.

I've done some test with different computers/locations all with 0% packet loss.

On my Windows laptop, I keep getting disconnected with this message on the server:
network_receive_data", "connection [%d] already closed"
Same for a Windows desktop in France with lower ping.

So at first I thought the issue was the server not being powerful enough.

But then I tried to connect with a friend's Macbook (on the exact same network so 0% packet loss) and to my surprise it was working perfectly.
No disconnection at all in more than 10 minutes.

My guess is that there's something wrong with the communication between a non-Windows server and a Windows client.


Connection already closed message on the server is normal when a client disconnects. You need to see what messages are on the client.