#UnreliableMaxMessage Size Exceeded - KCP

24 messages · Page 1 of 1 (latest)

minor iron
#

Hey everyone!

I'm having an issue where I'm exceeding the max unreliable message size on KCP. The exact error is:
Failed to send unreliable message of size 1205 because it's larger than Unreliable MaxMessageSize=1199

This is occurring because I have a lot of enemies with quite a few NetworkTransformChildren. I have in the past synced many enemies without hitting this issue - so I have a few questions.

  1. I presume I should not be looking at increasing this max size and should be taking this as a code/implementation smell - correct?
  2. Am I exceeding the message size of a given enemy - or are there too many enemies? IE. Are network transform messages handled on a per identity basis, or is it for the given network frame?
  3. Another approach that I can take is to remove all network transform children, and instead only sync the root and animation state - HOWEVER, enemies ragdoll on death and players can interact with the ragdolls. Does anyone have any recommendations on how to implement synced ragdolls over the network? Or should I just ditch having ragdolls for the sake of network performance?
  4. If everything on unreliable gets mashed into a single packet, in theory this means that I can only have 21 network transforms. (Syncing position 24bytes, and Rotation 56bytes) totaling 1176bytes . This seems incredibly low and I know that I've synced more than this in the past. Did something change - or am I misunderstanding something here?
distant nimbus
#

@minor iron Which Mirror version is this.
Im not familiar with new, but the older Mirrors could have thousands of NT's on unreliable fine.

#

How many NT's + sync vars + other network data is on each prefab?

#

Have you changed any KCP transport settings from the defaults.

minor iron
#

My thoughts exactly - getting info for you now.

#

Mirror: 2022.9.15
Unity: 2021.3.10f1

Default KCP settings (Using LRM with KCP connector).

Max Unreliable Packet size seems to be set based on MTU-overhead.

#

Current setup is ~100 enemies with a Network Transform, and 5 NetworkTransformChildren.

I could definitely improve the way that I'm doing that, or strip out ragdolls. However, it's concerning that it's falling over with only that. Especially since players will require a similar setup (VR).

distant nimbus
#

Ah LRM

#

Or new mirror

#

Is my two guesses

minor iron
#

I'd rule out LRM, the max unreliable packet size is purely defined by KCP. Unless something is bloating the data?

#

But the only network info being synced regularly by enemies is the transforms - and the issue goes away if I remove my enemies from the scene.

#

I'm not going crazy though - right? Mirror should be able to handle literal thousands of NTs, right?

minor iron
#

Will try update Mirror again sometime this week- but if anyone else has any suggestions or help, it would be appreciated!

minor iron
#

Finally got around to working on this again.

I've updated Mirror to latest store version, and updated LRM to Speidy's fork.

I even tried increasing the MTU size in KCP to 10200 (from 1200), an extreme, and the packets are somehow still exceeding that size. So I've reverted the change and continued to dig deeper.

I think I've isolated the issue between two areas of code, still need to dig deeper. I'm going to be rubber ducking here incase anyone feels like chiming in with any ideas.

All packets pass validation in the NetworkConnection.cs class, and no packet exceeds 1299 (MTU-HEADER) bytes. However, somewhere between that point, and SendUnreliable(ArraySegment<byte> message) in KcpConnection.cs, it seems that the message is increasing in size? Causing it to be larger than the allowed size.

This only happens on the server.

Starting to look very much like you were right (as usual :'D) JesusLuvsYooh

image.png
#

Client sending messages is tiny.

image.png
minor iron
#

Gotcha.... LRM is adding 9 additional bytes to the segment.

image.png
distant nimbus
minor iron
#

Confirm theory by swapping out LRM and test with only KCP. If that works, then evaluate a switch to EOS for relay.

Will also do some more digging through the code to see if it's a simple fix - but the low level stuff hurts my brain sometimes 😂

Power is currently out (I live in South Africa, we have rolling blackouts because of terrible corruption) so will dig back in when the power is back.

#

Thanks again for pointing out that it could be LRM or outdated mirror. That actually helped quite a bit! I always appreciate your help.

sage knot
#

not sure if it has been mentioned, but KCP algorithm doesn't do unreliable, but the KCP transport has a separate channel for it (so I assume separate settings)

#

and for unreliable message it is bad to fragment them into parts because if 1 part is lost then all of the have to be throw away. (like sending 5 fragments, 4 arrive, 1 dropped => those 4 that arrived have too bee thrown away)