Unity Transport not support mobile platform properly

It seems like Unity Transport doesn't work really well at mobile platform that currently I found it at Android platform. When the bug happens I will get error code -5 spamming and the game will become super unstable. I need to restart game to solve it. After restart and reconnect back the game to the same server, the game become smooth again. Actually did Unity have mobile project at production to battle test the transport at mobile platform?

Are you using Unity Transport directly, or through Netcode for GameObjects (NGO)? That is, are you using the com.unity.transport package directly or are you using the com.unity.netcode.adapter.utp wrapper?

That -5 error occurs when a network queue is full. The wrapper package for NGO is known not to handle this very gracefully. There are fixes incoming in the next version (1.0.0-pre.4) that should make this less painful to deal with.

1 Like

@simon-lemay-unity Thanks for reply. I’m using dots netcode.

I would tell you to ask about the issue on the DOTS NetCode forum, but I see you already did. :p

It's possible the error is raised because the maximum amount of in-flight reliable packets is reached (this is the window size setting of the reliable pipeline stage). The maximum is 32 so depending on usage it can be relatively easy to reach this. Unfortunately I'm not familiar enough with DOTS NetCode to know what kind of traffic is going through reliable pipelines, so I'm afraid I can't be of much help regarding this.

I do know that on the NGO side we've had issues related to fragmentation over reliable pipelines. We've made a few fixes in the transport package related to this (they're all in 1.0.0-pre.10). If you have not tried so yet, it might be worth a shot to force an update to the latest version.

I tried to force an update to the latest version before but seems like latest transport package has behavior changes that I guess needs to change some APIs and flow to make it works properly again. I would like to know how much has been changed since 0.8.0-preview.8? And what’s APIs and flow should I change and update to make it works again?

Oh wow, I hadn't realized the released version of DOTS NetCode depended on 0.8.0.

I'm not sure I'm aware of all breaking changes that happened since then. I know of at least one: BeginSend now returns the DataStreamWriter as an out parameter now rather than as a regular return value. But there might be others, and then there might be more subtle incompatibilities too. Forcing an update to 1.0.0 might be more trouble than I first thought.

I know it sucks to read this, but it might be simpler to wait for DOTS 0.5...

1 Like

@simon-lemay-unity Just want to check with u. Is that Unity Transport has started to battle test for mobile platform i.e. Android and iOS? Not sure whether it's fixed at latest Unity Transport version but at least at 0.8.0 seems like Android playing the game with mobile data network instead of wifi will have jitter and slow issue.

On the transport side, all our test suites (including performance tests) also run for mobile platforms. So the transport itself shouldn't be causing any significant extraneous delay or jitter. If it does I'd consider it a bug (at least for the 1.0.0 release, I'm not sure how well-tested previous versions were on mobile).

Although in your situation it might have more to do with the connection quality than the transport. You mention a difference in jitter and latency when playing on mobile data compared to Wi-Fi. To some degree, that is expected. Mobile data connections are often much more jittery than Wi-Fi, and there are more unknowns that go into their general quality (cell tower switching causing lag spikes or packet loss, throttling and/or QoS by the operator or on the backbone, congestion at the tower, etc.).

The transport offers a simulator pipeline stage to test a game using different latency, jitter, and packet drop rate values. This could be used to mimic different network conditions and test how a game handles them. I don't know how (or even if) this capacity is exposed in DOTS NetCode, though.

Thanks for bringing this to our attention. The code is written to correctly handle an overflow of the sequence number, but there was an instance where this wasn't done properly (although not in the write function). This will be fixed in the next release of the Unity Transport package.