Test build with an attempt to fix the lag

It looks like the lag was caused by my careless use of a feature in the Lidgren network library which allows sending messages through UDP reliably (= so that they’re resent if the recipient doesn’t acknowledge receiving them). In some cases that lead to severe congestion problems, causing enormous lag not just in the chat but all the reliable messages that the game sends. Rewiring devices, picking up or dropping items and attaching/detaching items were all synced using reliable messages, and there were definitely problems with all of those even though the chat lag was the most obvious effect.

I think I’ve managed to fix the problem though: the reliable messages are now sent using a homebrew packet loss detection system which allows me to slow down or cancel the resending process entirely if it seems like the line is choking (once again thanks to Glenn Fiedler his excellent articles which have helped me quite a few times during the development of Barotrauma).

However, I haven’t yet been able to test and verify that the fix is 100% working, because I still haven’t managed to reproduce the issue when playing the game on my computer. I did host a few “real” online rounds with 4-5 players and everything was working great, but it’s still possible that the problem re-emerges when there are more players. So, I decided to upload the current build so that I can use you guys as free testers in case you want to try a version that probably works much better than v0.2.2 while I try to get rid of any bugs in the new netcode and verify that it’s actually working.
tl;dr: Chat lag and a bunch of other networking issues probably fixed, try at your own risk by downloading the latest build here:

barotrauma_testbuild_3.rar

EDIT: The fix is now implemented in the latest version, v0.2.3.1

There’s also a bunch of other small additions and fixes in the build (such as being able to ban players and hit people in the face with a wrench).

 

 

FacebookTwitterTumblrGoogle+Share

8 comments

  1. I was curious about the networking performance, so I wrote a small program that relays all network messages that the game sends and receives when it’s connected to a server so I can generate some info about the connection. Counting the amount of packets being sent per second while a round is ongoing results in a number between 30-50 packets per second, both sent by the client and by the server. That adds up to around 80 packets per second. This seems a bit excessive, especially for a trusted-client networking model. Caching up a few actions and sending at a lower rate (10 packets per second would probably be good enough) could help prevent network congestion.

    1. There’s a debug command in the game btw which shows some network stats and a graph of bandwidth consumption: try entering “netstats” to the console. But yeah, there’s still a lot of work to do with the network code… Do you think it would be better to combine messages and send fewer larger packets instead of many small ones? I haven’t really paid much attention to the number of packets and currently the game sends the data for each object as a separate message. The bandwidth consumption still seems somewhat reasonable to me, even though it’s a large number of packets they’re generally pretty small.

      1. Fewer large packets (not more than 1500 bytes) are probably better than many small ones because routers like buffering packets to make sure they go somewhere, so they could be wasting resources by having too many packets.

  2. Getting an error when trying to download an update in the launcher, it won’t let me copy and paste the message but this is the general gist:

    Error while downloading: System.Net.WebException: The remote server returned an error (404 not found)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>