[SteamNetworkingSockets] A ConnectionRequestMessage was received from a client when the connection has already been established (Netcode 1.5.2)

[A1win]

We started to get this error after upgrading our project from Netcode version 1.2.0 to 1.5.2.

This doesn't occur with Unity Transport when running two instances of the project on the same machine. I don't have an easy way to test this over the Internet using other transports.

Also reported on Netcode issue tracker: Unity-Technologies/com.unity.netcode.gameobjects#2704

Description

When a client attempts to connect to a hosted server (using SteamNetworkingSockets Transport), the host sometimes gets the following error, and the client is unable to connect.

I've redacted the "message content" in the error message in case it contains Steam IDs or other private info. Let me know if it would be useful to have.

[Netcode] A ConnectionRequestMessage was received from a client when the connection has already been established. This should not happen. Please report this to the Netcode for GameObjects team at https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/issues and include the following data: Message Size: 90. Message Content: <redacted>
UnityEngine.Debug:LogError (object)
Unity.Netcode.NetworkLog:LogError (string) (at ./Library/PackageCache/[email protected]/Runtime/Logging/NetworkLog.cs:34)
Unity.Netcode.NetworkManagerHooks:OnVerifyCanReceive (ulong,System.Type,Unity.Netcode.FastBufferReader,Unity.Netcode.NetworkContext&) (at ./Library/PackageCache/[email protected]/Runtime/Messaging/NetworkManagerHooks.cs:79)
Unity.Netcode.NetworkMessageManager:CanReceive (ulong,System.Type,Unity.Netcode.FastBufferReader,Unity.Netcode.NetworkContext&) (at ./Library/PackageCache/[email protected]/Runtime/Messaging/NetworkMessageManager.cs:325)
Unity.Netcode.NetworkMessageManager:HandleMessage (Unity.Netcode.NetworkMessageHeader&,Unity.Netcode.FastBufferReader,ulong,single,int) (at ./Library/PackageCache/[email protected]/Runtime/Messaging/NetworkMessageManager.cs:407)
Unity.Netcode.NetworkMessageManager:ProcessIncomingMessageQueue () (at ./Library/PackageCache/[email protected]/Runtime/Messaging/NetworkMessageManager.cs:458)
Unity.Netcode.NetworkManager:NetworkUpdate (Unity.Netcode.NetworkUpdateStage) (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkManager.cs:42)
Unity.Netcode.NetworkUpdateLoop:RunNetworkUpdateStage (Unity.Netcode.NetworkUpdateStage) (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkUpdateLoop.cs:185)
Unity.Netcode.NetworkUpdateLoop/NetworkEarlyUpdate/<>c:<CreateLoopSystem>b__0_0 () (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkUpdateLoop.cs:208)

Reproduce Steps

1. Host a server with Steam Networking Transport.
2. Connect to the hosted server as client. Latency might be a factor (this occurred to us when connecting between Europe and North America).
3. Repeat the steps multiple times.
4. Notice that the client is sometimes unable to connect and the host gets an error.

Unfortunately, we don't have a small test project to share.

Actual Outcome

Hosted server gets an error and prevents a client from connecting.

Expected Outcome

Hosted server gets no error and client is able to connect.

Environment

• OS: Windows 10
• Unity Version: 2022.3.10f1
• Netcode Version: 1.5.2
• Netcode Commit: Unity-Technologies/com.unity.netcode.gameobjects@3636884

[ShadauxCat]

Just to provide context on why this happens with 1.5.2: In 1.5.2, we added extra packet corruption detection mechanisms to help ensure that all of our code is behaving properly. One of these mechanisms we added was to detect and reject Connection Request messages received more than once from the same client, which could happen for three reasons (that I can think of off the top of my head):

1. The transport re-delivered a message that had already delivered, or
2. Packet corruption caused the header to be overwritten with 0s (because Connection Request is message ID 0), or
3. Data was delivered from the transport that was not at a correct boundary for a message (i.e., it delivered us a message that started in the middle of another message)

So there isn't new behavior in 1.5.2 that would be causing this. This would have been happening in old versions as well. We were just silently accepting these duplicate or corrupt packets, and in 1.5.2 we added code that detects this error condition and reports it.