Multiplayer server connection issues

The next update will be available on Wednesday, December 18, in the early evening (GMT+1).

This update will not yet replace the Java version, instead it is the actual content update. We'll provide more information about the transition together with the update.

    I'm glad to hear it works now! :):thumbup:


    About the UDP Flood Protection, was there also an adjustable threshold value? Depending on this value, it may indeed interfere with multiplayer servers: while a single client typically doesn't send enough packets to trigger that (unless this is set to a very low threshold value), this could easily happen if there are multiple clients on the server. Depending on how this is implemented in that particular router model (which router do use exactly?), the router may block these ports.

    It's a Draytek Vigor 2860


    It was a set to a very low value. I believe it had been changed some time in the past to test something for a client and never set back. *facepalm*


    So I'll hold my hand up for causing this myself. :hushed:


    I also updated the firmware on it (was slightly out of date) I did this at the same time so it could have been a firmware oddity but the UDP FP seems most likely.

    Oh, I see :D Probably this wasn't an issue in the Java version, considering that only player sync was sent via UDP there (every 80 ms, so this probably didn't trigger the flood protection). The new version, however, sends everything through UDP (and unlike the Java version, it only uses a single port for networking) ^^

    i can confirm the issue, windows server 2019. ran fine until the last update. loading players get stuck at 5% with no client server requests. i simply restart the server and it works for a few hours then fails again. using pfsense for my router with a cisco 24 port switch. ive looked at all the the ports and everything is fine.

    Updates:


    Turned on UDP logging on firewall -- no DROP UDP logs (for associated ports)

    Turned off firewall temporarily -- issue persists.

    Router restart -- issue persists.

    Client restart -- issue persists.

    Server restart -- working :dizzy: (for now - I did do this earlier (first thing I tried) and it did not work)


    Info:


    Firewall is built in windows firewall

    TCP/UDP ports open on router and pointing at servers local IP

    Ports on server are open on windows firewall

    RisingWorldServer.exe is on the Allow apps through firewall list

    This is really strange :wat: So far this only seems to affect Windows servers, but I see no reason why that should happen (except something related to firewall etc, but it's weird that it was apparently working before) :thinking:


    How often do you restart your server? Do you use the built-in "restart" command (or the built-in scheduler), or do you actually kill the process and start a new one?


    Could you maybe share the latest server logs (for the Logs folder)? Maybe you could send them via PM to me?



    //Edit: After some investigation, it seems like the UDP port sometimes still stays active for a brief moment after shutting down the server. If the server gets restarted immediately (either by the built-in restart command, or by killing the process and restarting it manually), this results in the old UDP listener not getting closed. This only seems to happen when binding to all addresses (i.e. if no specific server ip is provided). Apparently this was already happening in 0.3 (the previous multiplayer update). We're looking for a solution and will provide a fix for this ASAP!

    There is now an update available for Windows multiplayer servers specifically. It should fix the UDP issue mentioned above, at least we couldn't reproduce it anymore on our end. This version also performs a port scan (to find out if there is already a TCP or UDP listener on the server port), but this can be disabled by setting "Server_EnablePortCheck" to false in the server.properties.


    This fix is not available for Linux currently because apparently Linux servers were not affected by this issue. However, if you still run into any connection issues (either on Windows or Linux) or any other server-related issues, please let us know :)

    i had noticed in the last update if you closed the server and restarted it would take a few minutes to reconnect, i just dealt with it. the issue with players getting stuck at 5% had never happen before so i figured it was a new issue. thanks for all the hard work

    Quote from james1bow

    i had noticed in the last update if you closed the server and restarted it would take a few minutes to reconnect, i just dealt with it. the issue with players getting stuck at 5% had never happen before so i figured it was a new issue. thanks for all the hard work

    Do you mean the last update (i.e. 0.4), or the latest hotfix that was just released an hour ago? If the server takes a few minutes to reconnect, it could be the port checker which halts the server until all ports are open (this was actually already implemented for TCP connections, but only the recent hotfix also takes UDP into account).

    Do you have access to the server console? In this case there could be an indicator what's taking to long. If it's the port checker, you will see an ongoing output like "Checking ports...." (with lots of dots behind it if it takes long). If it's not the port checker, it could be Steam which takes a long time until it's connected (Steam is fully connected if you see this message in the log: "[STEAM] Server connected, public IP -> x.x.x.x").


    How did you restart the server exactly? If you kill the process, it typically takes some times until the TCP connections (for the server query port) gets closed automatically on Windows. But if you shutdown the server gracefully (either by using the "restart" or "shutdown" command), the server should be able to restart immediately.

    Quote from red51

    Do you mean the last update (i.e. 0.4), or the latest hotfix that was just released an hour ago? If the server takes a few minutes to reconnect, it could be the port checker which halts the server until all ports are open (this was actually already implemented for TCP connections, but only the recent hotfix also takes UDP into account).

    Do you have access to the server console? In this case there could be an indicator what's taking to long. If it's the port checker, you will see an ongoing output like "Checking ports...." (with lots of dots behind it if it takes long). If it's not the port checker, it could be Steam which takes a long time until it's connected (Steam is fully connected if you see this message in the log: "[STEAM] Server connected, public IP -> x.x.x.x").


    How did you restart the server exactly? If you kill the process, it typically takes some times until the TCP connections (for the server query port) gets closed automatically on Windows. But if you shutdown the server gracefully (either by using the "restart" or "shutdown" command), the server should be able to restart immediately.

    when i said least update i meant 0.3. i have a script that kills the process, i will do a better job shutting down the server as i do get the checking port..... ive installed the hotfix and will keep an eye on it

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login