Server shutdown when receiving a disconnection message from an already disconnected client

[Goreduc]

Description

When connection manager is receiving disconnection message, it uses TransportIdToClientIdMap and ClientIdToTransportIdMap to find the client and manage the disconnection.
However if the message is received twice, the client no more exists the second time in the maps. A warning is raised

[Netcode] Trying to get the NGO client ID map for the transport ID (4178184557) but did not find the map entry! Returning default transport ID value

But the default value "0" correspond to the server. As a consequence, the disconnection process is executed for the server

Reproduce Steps

The bug is easily reproductible using Facepunch, but should be reproductible in other cases

• Server is started
• A client try to connect
• Connection approval is called on server side
• Server decide to refuse the connexion
• Both the client and server are disconnected

Actual Outcome

Server is disconnected

Expected Outcome

A message adressed to a disconnected client should be ignored

Screenshots

Environment

• OS: Windows
• Unity Version: 2023.2.15f
• Netcode Version: 1.8.1
• Netcode Commit: ?

Additional Context

Discussion can be found here :
https://forum.unity.com/threads/ngo-facepunch-problem-when-approval-is-refused-for-a-client.1525018

[NoelStephensUnity]

@Goreduc
I will look into this issue, but I would like to point out that this is a bug in the facepunch NetworkTransport implementation that then results in unexpected erroneous behavior (i.e. getting the disconnect message twice from the same client).

@fluong6
I migrated this down to medium since it is an issue with FacePunch and we are trying to prioritize other high priority issues that are due to our supported scope. Keep the imported issue as we should try to make this part of our code more fault tolerant and I do believe the fix should not be that time consuming.

[michalChrobot]

Hey, I believe that the issue was resolved as part of NGO v1.10.0

[Goreduc]

Hey, I believe that the issue was resolved as part of NGO v1.10.0

Hey,
No, still reproductible in NGO v2.1.1

(tested with Facepunch Transport for Netcode for GameObjects from https://github.com/Unity-Technologies/multiplayer-community-contributions?path=/Transports/com.community.netcode.transport.facepunch, version 2.0.0)

[michalChrobot]

Hmm, ok then, let me investigate on it. Thanks for the information!