ArgumentOutOfRange_NeedNonNegNum when recieving large data in RPC

Unity Engine
, ,
1

Hello!

I run into an unexpected issue when sending big Arrays (800 Vector4s) in an RPC.
Generally it works fine, however after some time out of the blue i receive this Exception:

ArgumentOutOfRangeException: ArgumentOutOfRange_NeedNonNegNum
Parameter name: count
System.ArraySegment`1[T]..ctor (T[] array, System.Int32 offset, System.Int32 count) (at <00000000000000000000000000000000>:0)
Unity.Netcode.Transports.UTP.BatchedReceiveQueue.PopMessage () (at <00000000000000000000000000000000>:0)
Unity.Netcode.Transports.UTP.UnityTransport.ReceiveMessages (System.UInt64 clientId, Unity.Networking.Transport.NetworkPipeline pipeline, Unity.Networking.Transport.DataStreamReader dataReader) (at <00000000000000000000000000000000>:0)
Unity.Netcode.Transports.UTP.UnityTransport.ProcessEvent () (at <00000000000000000000000000000000>:0)
Unity.Netcode.Transports.UTP.UnityTransport.Update () (at <00000000000000000000000000000000>:0)

This exception will continuously spam every frame after the first occurance. In the log i see nothing particular happening when it first occurs

Did i run into some size limitation of the Transport, or what could be happening here?

Running client on Android (Meta Quest 3) with a Dedicated Windows Server.

Netcode for Gameobjects v1.8.1 using Unity Transport v1.4.1

Thanks for any tips!

2

That’s 12,800 bytes! :anguished:

First order of business: avoid doing that! Just in general, the RPC system is not meant or designed to send large amounts of data. If you send 2+ of these in a single network tick you could easily hit the packet size limit (somewhere about 32k I believe) and cause a transport failure, more so if there’s more other traffic going on.

So question is WHY do you send all that data? Do you really have to? Can this data be precomputed or reconstructed deterministically on the other end? Can it be sent compressed, eg rather than 4 floats send 4 half-float or delta values or RLE/ZIP compressed? Can it be sent in fragments? Can it be sent at a lower frequency eg once per second?

Using the custom messages system may also give you more headroom but I don’t think the RPC overhead amounts to more than a couple dozen bytes.

As to the actual error, you may be able to work around this by increasing the send/receive buffers in the Inspector of the Transport. But this should only be used for a temporary solution or if you run this with known hardware for a limited (closed) audience and won’t pay for server traffic or get shunned for higher than usual battery drain.

3

yeah, i honestly was surprised that it workes as good as it does! normally it runs for a couple of minutes without issues… i was however expecting a more meaningful error message when overstepping the limit.

i will try reducing the sent data and see if that changes anything. :slight_smile:

4

For the specific error you’re getting, I’d suggest updating your Unity Transport package, either to version 1.5 (or better yet, 2.3). That error looks like a reliable stream corruption bug, and it just so turns out that the latest versions of the package contain a fix for that.