LNL window size setting testing

[Frooxius]

Hello everyone!

I've got another test for you! This is a potentially realtime networking breaking change, so I want to test it out first before pushing to main.

Build Version

TESTING HAS ENDED

What is being tested

Resonite session can suffer from a "packet queuing" issue, where an user falls behind in the session due to the packet transfer rate being too slow, particularly with high latency connections. This happens due to LNL library throughput decreasing dramatically with increasing latency between the users.

The throughput can be increased by increasing the window size - how many packets can be in flight at any given time. However this also risks destabilizing the connection by sending too many packets. There's no "one size fits all" solution.

To resolve this, I've been working on adding new capability to the LNL library which allows the window size to be adjusted dynamically, so it can adapt to the networking conditions.

This is the first part of that implementation. It allows the LNL window to be changed on the fly - however it won't change it automatically for you - instead it is made into a setting in Resonite's UI. Changing this setting changes the window size for all your connections immediately (unless you're the host).

Since this required some restructuring on how LNL handles sending and receiving packets, it's possible this has broken the library in some way - this is what I'd like to test at this stage and validate that those changes haven't broken the library.

We will NOT be testing effects of this change yet - e.g. which window sizes work well in what conditions - if this testing passes, we'll push this to main, so people can use this setting as a workaround when they queue, while we gather data to make the adjustments of this value fully automated.

How to test

• On Steam, switch to the prerelease branch and make sure the build updates before you run it
• Make sure your build version matches the one at the top of this message

You will need to test with multiple users since this specifically affects networking.

• Host or join sessions with other users
• If you're joining other users, make sure you're not forcing connections through relay - we want to test direct connections where possible!
• If you joined a session, try fiddling with the LNL Window Size setting now and then, changing it during the session
• If you're host, the LNL Windows Size setting is irrelevant - the system will use the window size setting of each user who has joined
• Have everyone do potentially network intensive stuff - open and mess with inspectors, protoflux and interactive things, import assets
• Observe if networking stops or if changes to the world stop updating at some point

What NOT to test & report

• If the connection quality degrades when you set the window size too low or too high - this is expected, the range is pretty large for testing purposes, but you're not expected to run at very high values (or very low ones) in most cases
• Which values help with packet queuing - you can test this for yourself, but please don't make detailed reports of these at the moment (quick mention of observations is ok), that will be focus of the next phases - right now, we just want to verify if networking breaks or not with these changes
• Other unrelated changes that are present on the main build

If you find something that got broken

• You can report issues directly here (this is a very specific test, so we don't need issues created for each)
• Make sure to include the log
• Please include description of what happened. Be succinct, but exact.
• Ideally provide video if you have one
• Specify if you were host / joined user and what your LNL Window Setting values were
• How many users were in session?

If you find that stuff works okay

Please report it too and include details - how many users, where is the host, where were users (if you know), how long did the session run for, what did you (roughly) do and such. This way we know things are working okay.

Are there bridges & relays for this test?

Just one running on one of my test machines. This should be sufficient for the validation test, once these changes are validated, we'll deploy new bridges & relays more globally.

If you end up connecting through the relay, you might not have best performance with this - however the goal of these changes is so you don't need to use the relay.

How long will testing go for?

With the nature of the changes, we expect the issues to become apparent relatively quickly, so unlikely more than a few days. Once we get a good feel that there's no breakage, this will get merged to main build and we'll continue to the next phase.

[ohzee00]

Hey! I think something might be wrong with the prerelease currently, I can only connect to others by Steam networking sockets.

I have tried disabling Lan, preferring steam networking sockets (as a test), forcing a relay and then completely shutting down steam, all of which still causes me to use steam networking sockets without even trying LNL. When disabling steam I was not able to connect to any sessions my friends were hosting on the prerelease.

I have also tried being the host, joining two different friends and each friend hosting their own session, all of us were on steam networking sockets and thus couldn't test this prerelease.

This is the log when I had Steam disabled and thus couldn't connect at all:
DESKTOP-V75BHJO - 2024.7.1.798 - 2024-07-02 03_23_03.log

This log all I did was get invited to a friend's session while I had steam on, I connected via steam networking sockets:
DESKTOP-V75BHJO - 2024.7.1.798 - 2024-07-02 03_31_07.log

From my understanding, it isn't even trying LNL to begin with?

Bredo's suggestion below fixed this, I was able to test by direct lnl connections and according to them the bridge seems to be down

[bredo228]

Just tested, LNL direct connection works but (unsurprisingly) punchthrough doesn't work due to the current lack of a bridge.

[ohzee00]

Just tested, LNL direct connection works but (unsurprisingly) punchthrough doesn't work due to the current lack of a bridge.

May I ask how you would do a LNL direct connection with another user? Given the ports are random for simple invites I couldn't do such

[bredo228]

Just tested, LNL direct connection works but (unsurprisingly) punchthrough doesn't work due to the current lack of a bridge.

May I ask how you would do a LNL direct connection with another user? Given the ports are random for simple invites I couldn't do such

I did this with a headless, if you want to test I'll leave one running for a bit: lnl://us01.voxelbone.cloud:11250

Use the "Open World" node as such to direct connect:

When creating a world from the graphical client, you can specify a port the session will run on and allow that through any firewalls, should allow you to connect directly

[ohzee00]

Oh I knew I wasn't imagining a port input somewhere, thank you for the write up!

[Frooxius]

The bridge & relay are back up! The power went out while I was asleep, sorry!

[ohzee00]

After allowing friends to manually connect with Bredo's suggestion I was able to test this, we just kinda played in a grid space world with various gadgets and vehicles and we experienced no network weirdness besides when I was trying to do the entire bee movie^bee movie script every update tick- which was just to test something really intensive. For this test it was me hosting with two other friends that were in the same country.

I even used a object that has driven and undriven dynamic variables that caused a sheer amount of corrections but given how close the two friends were however there was no desync and the session operated fine. We also tested at different window sizes on the fly, besides my own network not being able to handle it (which isn't special, I only have 9mb upload) nothing was wrong at all and the session stabilized afterwards.

So overall in a regular session that was doing really heavy stuff for roughly a hour, I found no unexpected behavior- with the only disruptive behavior being my own network being horribly strained due to the bee movie script on a Update node.

Only thing I did not test was uploading assets, perhaps others can do a more involved session that tests that.

[Frooxius]

Just a heads up, are there any more planned tests for this?

Right now it seems that this change is mostly good. We can a big BoTC game, which seemed to work okay (other than the server dying at one point, but it's likely it ran out of RAM and after restart the game finished fine). And the other reports seem to be okay too.

I'll need to use the prerelease branch for another testing of the new type system soon, but I wanted to check if anyone still plans to do any tests before I replace the build in the branch.

[bredo228]

As far as I am aware, I don't think there are any tests planned currently.

[Frooxius]

Ah thanks! I'll leave this for a day at least in case someone shows up and then I'll swap out the builds and do the type testing.

[Frooxius]

I'm closing the testing now, thank you!