assembly_valheim.dll swap for recv 64 kb/s limitation override (less lag / desync)

[Hydeo]

Hi,

It seems that removing the 64 kb/s limit on the data player share together fixes a lot of the sync / lag issues with very dense world.
If one were to try to swap the OG one for a modified one, what would be the best approach ?
I'm running this great image on linux but I guess on Windows it wouldn't be that much different ?

You can read some about it here :
https://www.reddit.com/r/valheim/comments/lkea78/valheim_dedicated_server_lag/

Thank you for providing this Image, it has helped me a lot :)

[lloesche]

I just tested it and it works on Linux as well since the server is just using the same mono dlls on Linux as it is on Windows.

I wonder if there is a good way of incorporating this into the image. The dnSpy process is pretty manual so for every update somebody would have to manually create the new dll with changed bandwidth limit and create a binary patch for it.

We could add a new env var TRY_BANDWIDTH_PATCHING which defaults to false and if turned on could use bsdiff/bspatch to apply the manually generated binary patches for assembly_valheim.dll with well known sha256 checksums. The resulting binary patch is around 180kb in my test so wouldn't bloat the image too much.

But then the new limit gets compiled into the dll so can not be changed at runtime. So I'm not sure what would be a sane value there. Some people would only want to double to 128k others might want to 10x to 640k.

Maybe instead of binary patching the server we should petition Iron Gate to make it a config variable in the first place 🙂

[Hydeo]

I'm not really Docker savvy but that wouldn't that be one of the advantage of Docker ?
Even it i cannot be change it at runtime, starting another container with another value would just take a few seconds, and in any case a restart of the server is needed.

[lloesche]

What I meant is if we wanted to ship a binary patch for the container - so that users don't have to manually patch and compile their own DLL - we'd have to ship one for each version of the DLL and each value of m_dataPerSec. It is going to become one large matrix of versions and values to support since we can't update them at runtime. Like, lets say we wanted to support 128k, 256k, 512k and 1M. Then each time a server update is released somebody has to manually create those four DLLs one for each value and add them to the repository.

[Hydeo]

Sure, i was thinking more of a fixed modified value waiting for the devs to add an option themselves.
Anyway I fully agree with your last comment here, that should probably be a V+ concern.

[InB4DevOps]

I also just tested it.
I modified the DLL with dnSpy, stopped the server, copied the modified DLL back to the server.
After I started the server however the file had its original file size again so I guess it was restored to its original state (original is 893.440 bytes, changed DLL is 892.928 bytes)

(I have mounted /opt/valheim_dl to a folder on my NAS)

How did you get around this @lloesche ?

I also just found this in my log, so it was in fact the updater?

2021-02-19 10:45:23,stdout,"2021-02-19 10:45:23,274 INFO spawned: 'valheim-server' with pid 56
"
2021-02-19 10:45:23,stdout,Valheim Server was updated - restarting

2021-02-19 10:45:23,stdout,>f..t...... valheim_server_Data/Managed/assembly_valheim.dll

2021-02-19 10:45:23,stdout,.d..t...... valheim_server_Data/Managed/

2021-02-19 10:45:22,stdout,.d..t...... ./

[InB4DevOps]

I'll try a read-only file mount. Thanks.

EDIT: works like a charm.

[alexdie]

I couldn't get a read-only file mount to work. With the following setup, the valheim server crashes and restarts in a loop.

    docker run --restart=always -d \
    --name valheim-server \
    -p 2456-2458:2456-2458/udp \
    -v $HOME/assembly_valheim.dll:/opt/valheim/valheim_server_Data/Managed/assembly_valheim.dll:ro \
    -v $HOME/valheim_config:/config \
    -v $HOME/valheim_dl:/opt/valheim_dl \
    -v $HOME/valheim:/opt/valheim \
    -e SERVER_NAME="XXX" \
    -e WORLD_NAME="Dedicated" \
    -e SERVER_PASS="XXX" \
    lloesche/valheim-server

[InB4DevOps]

I think you mounted the wrong folder inside the container
my mount looks like this:

Checkbox is for read-only

Try to mount with /opt/valheim_dl[...] instead of /opt/valheim/[...]

[Cyborgmatt]

I'll try a read-only file mount. Thanks.

EDIT: works like a charm.

After mounting the read-only file did you not have issues with the auto-updater getting triggered every interval? That's what I'm experiencing at the moment.

[InB4DevOps]

I'll try a read-only file mount. Thanks.
EDIT: works like a charm.

After mounting the read-only file did you not have issues with the auto-updater getting triggered every interval? That's what I'm experiencing at the moment.

The auto-updater gets triggered regardless of the ro file mount. But the file can not be overwritten so it keeps working.

[alexdie]

Thank you for the suggestion. Unfortunately both paths lead to the same issue.
I've also tried not mounting /opt/valheim at all, and it doesn't change anything.

I always get the error

[S_API] SteamAPI_Init(): SteamAPI_IsSteamRunning() did not locate a running instance of Steam.
[S_API FAIL] SteamAPI_Init() failed
[Steamworks.NET] SteamAPI_Init() failed. Refer to Valve's documentation or the comment above this line for more information.

during server start up. I'm thinking that my modified .dll is the issue, but I've re-done that a few times with no luck.

[InB4DevOps]

Does the container work when you don't have the dll mounted?
Please try a freshly downloaded container image from tag latest.

[alexdie]

Yes, it does. No luck with completely removing and redownloading the container and image either.

[lloesche]

That is peculiar. I just tried with the same command you pasted above and it started all the way to

02/20/2021 23:20:40: DungeonDB Start 479

When I check the mounts inside the container they look like this:

root@58c778630088:/opt/valheim# mount | grep valheim
/dev/sdd on /opt/valheim type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)
/dev/sdc on /opt/valheim_dl type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)
/dev/sdd on /opt/valheim/valheim_server_Data/Managed/assembly_valheim.dll type ext4 (ro,relatime,discard,errors=remount-ro,data=ordered)

...
-rwxr-xr-x 1 root root   74752 Feb 20 23:18 assembly_sunshafts.dll
-rwxr-xr-x 1 root root   28160 Feb 20 23:18 assembly_utils.dll
-rwxr-xr-x 1 1000 1000  892928 Feb 20 23:18 assembly_valheim.dll
-rwxr-xr-x 1 root root 2456576 Feb 20 23:18 mscorlib.dll
-rwxr-xr-x 1 root root    2082 Feb 20 23:18 response.rsp
root@58c778630088:/opt/valheim/valheim_server_Data/Managed#

I usually don't volume mount /opt/valheim as the only penalty is some extra startup time to rsync the folder but just to be sure I have a similar setup as yours I included it.

Have you tested the modified dll on another system like your Valheim game client? I.e. are you sure the issue is not with the modification?

[alexdie]

The issue was absolutely the dll. The initial .dll worked on my client and dedicated server on my machine, however since I redownloaded the original dedicated server dll and modified it again it works.

[leepfrog-ger]

Ran into the same issue and can confirm that the assembly_valheim.dll differs between the steam server and client downloads (checksums differ). When you just take the game dll, modify and compile it, it will run on the game client just fine, but on the server it will cause the above issue.
When you download the dedicated server version in steam, take that DLL and modify it, everything works fine.

[lloesche]

I think the most viable way of supporting this is to wait for #63
and do a PR against ValheimPlus to support modification of m_dataPerSec in the Server section.

[hasechris]

Hello all,

what if player dont want to mod their client game? That brought on a really lengthy and annoying discussion on our discord server.

I also think the game devs should (and maybe already are) implementing a better network-code, but in the meantime a solution in this docker container would be very sweet. We sadly run our valheim server on a rented vserver with 4 real cores (on a Xeon CPU E5-2630 v4 @ 2.20GHz) and have problems with lag and de-sync of clients starting with 6+ people on the server

I tried to include the mentioned dll file into my container with a readonly bind mount, but all it did was to stop the container from starting...

[Toucan-Sam]

@hasechris ValheimPlus support is included in the container and provides this feature. Please see the README.md file about how to enable it. You should not need to modify the assembly_valheim.dll manually anymore.

Finally, certain settings, like dataRate and forcing users to always be visible on the map don't require clients to install the mod. If you want to avoid this lag, don't use tools like hoes or pickaxes to modify the ground in areas of high population. As it stands, there is no way currently to fix that. Many performance issues are related to the way Valheim handles data. Clients currently have a big impact on performance. Get someone with high latency or a slow connection and everyone will suffer until they leave.

My primary server is 4 core, 4GB of memory and has had at least 15 people on it at one time without issues (until they started modifying the ground).

[kparkov]

Can I enable V+ just for data rate, and not install it on any clients?

[hasechris]

Hi @Toucan-Sam,

first of all, thanks for your quick answer.

Finally, certain settings, like dataRate and forcing users to always be visible on the map don't require clients to install the mod.

Yeah, that would be super sweet, but i already tried that. I just enabled the Valheim Plus option for dataRate and the valheim client of my wife's pc just throwed the error Incompatible Version found. I manually checked the versions of my server and the client and they were identical.

Because of this i interpreted that Valheim Plus always needs a modded client. Also on the Valheim Plus Github and Documentation i didn't find anything regarding not modding the client.

Greetings,
hasechris

[Toucan-Sam]

@kparkov @hasechris Please review the [Server] section of the V+ mod configuration. Your answer is there. :)

[Toucan-Sam]

Sorry, I feel like I'm being this guy a lot right now...

I love the idea of the mod and will add it myself, but Valheim is early access. Before solving this problem of modding things, might be practical to reach out to the devs and see if they have the intention to solve this themselves or at least expose it as a setting in an upcoming patch.

This 'feature' has got a lot of attention recently and I can't imagine the devs not addressing it relatively soon?

[Hydeo]

That's why the conclusion was not to implement any fix in this repo but let V+ do the job and add support for V+ here.
Valheim + offers a lot more than just this specific fix.

[gymnae]

I also opt for keeping mods out for now, rather make it heard with the developers.