Skip to content

fix: Address packet overflow issues in the UTP adapter (1.1.0) #1415

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Nov 16, 2021

Conversation

simon-lemay-unity
Copy link
Contributor

This is a backport of PR #1403.

Changelog

com.unity.netcode.adapter.utp

  • Changed: Removed 'Maximum Packet Size' configuration field in the inspector. This would cause confusion since the maximum packet size is in effect always the MTU (1400 bytes on most platforms).
  • Fixed: Packet overflow errors when sending payloads too close to the MTU (was mostly visible when using Relay).

Testing and Documentation

  • No tests have been added.
  • No documentation changes or additions were necessary.

It doesn't mean anything now. Anything sent on fragmented pipelines will
be broken up at 1400 bytes boundaries, and everything sent on a
non-fragmented pipeline is limited to a maximum size of 1400 bytes
(including overhead from the underlying protocols). Allowing to set that
limit can only lead to confusion among users.
This is not the cleanest of solution, but until we figure out something
better in UTP, this can at least unblock Boss Room.

The core issue being fixed here is that we'd allow sending payloads up
to the MTU in size on a non-fragmented pipeline. But that's incorrect
since UTP must add its own overhead to the payload. If sending a payload
close to the MTU in size, the overhead would bring the total packet size
over the limit of the MTU.

Since UTP lacks a good way of figuring out what's the actual maximum
payload size that can be sent, for now we patch over the issue by
sending everything on a fragmented pipeline.

The exception is the unreliable messages. The fragmentation pipeline
doesn't cleanly handle having multiple fragmented payloads in flight
(and possibly arriving out of order). The reliable pipeline stage fixes
that, but for unreliable traffic it's better not to fragment it.
Which is 2000 bytes. We won't need to hardcode that default value when
the new NetworkSettings API lands. So having a magical number floating
like that in the code is a temporary thing.
@andrews-unity andrews-unity merged commit 07450c6 into release/1.1.0 Nov 16, 2021
@andrews-unity andrews-unity deleted the fix-1.1.0/adapter-fragmentation-issues branch November 16, 2021 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants