Interrupting joining process causes the host to crash.

[nitrocss]

Interrupting joining process causes the host to crash. Important: I couldn't reproduce the bug with 1 PC. I reproduced it with 2 different PCs in the same city. (might require a bit of lag). I did it three times in a matter of a couple of minutes, so it is definitely a problem that is reproducible, and abusable.

Repro steps:

1. Host the game
2. Join as a client from a different PC.
3. When a bit of time passed (but before client connected), I sent another join request, and then another join request, and then one more. Then I let it cook.
4. The host crashed.

This might be directly related to issues with other transport layers:
Especially important is the second link, as one person seems to have fixed the issue for facepunch transport layer.

Unity-Technologies/com.unity.netcode.gameobjects#2804
Unity-Technologies/multiplayer-community-contributions#245 (comment)

[nitrocss]

Hello, some good news!

This issue is connected to #508.

The problems started appearing recently, probably because of the palworld situation (it's huge, EOS seems to lag a lot, might be connected heh).

By enabling all the possible logs for netcode and EOS, we figured out that it seems the problem lies here within NGO's NetworkManager:

When "Client Connection Buffer Timeout (default value = 10)" is 10, then it sometimes fails, causing both player and host getting kicked. When decreasing the value to 1, you see the crash every connection. When increased to 30, it doesn't happen anymore at all. This explains why the issue has only started happening recently for us.

Another issue is that kicking players doesn't work properly, as it kicks host too. This is actually the same issue that causes the host to kick itself when the client fails to connect.

We figured out a way to fix it inside netcode for gameobjects:

Packages/com.unity.netcode.gameobjects/Runtime/Connection/NetworkConnectionManager.cs

It seems that the problem is that the DisconnectEventHandler for some reason calls the disconnect twice, and it returns id 0 most probably because it's a default value when it fails to resolve id. However, we tested this a bunch of times today, and this fixes the problem for NGO. Now I don't know if this is something caused by EOSNetworkTransport, or a bug within NGO, but this is a fix for any other developer out there until this gets fixed internally, whether it is in this plugin or NGO.

My main request here is to:

1. Investigate this id issue in the transport layer
   and
2. Do you maybe know if there's a way to reduce the join time on EOS? Sometimes it seems like we get a good EOS connection, the join time is ~2-4 seconds, and sometimes it went up to 15 seconds! Again, increasing the "Client Connection Buffer Timeout", caused us to be able to connect anyway, but this seems quite bad. I'm assuming the problem lies within Unreal SDK.

[paulhazen]

@nitrocss Great info! I will look into this and get you some answers by EOD.

[paulhazen]

In RE: the following:

2. Do you maybe know if there's a way to reduce the join time on EOS? Sometimes it seems like we get a good EOS connection, the join time is ~2-4 seconds, and sometimes it went up to 15 seconds! Again, increasing the "Client Connection Buffer Timeout", caused us to be able to connect anyway, but this seems quite bad. I'm assuming the problem lies within Unreal SDK.

AFAIK, there is no way to reduce the join time, as that is dependent on the server response time and network conditions between the game and Epic Online Services servers. That is to say, there is no exigent performance bottleneck in the EOS SDK or the plugin. While I investigate the ID issue in the transport layer, I will look into this and confirm that it is the case, because I agree that is suboptimal performance, and if there's anything that can be done on our end to speed it up it would be good to know.

[paulhazen]

It seems that the problem is that the DisconnectEventHandler for some reason calls the disconnect twice, and it returns id 0 most probably because it's a default value when it fails to resolve id. However, we tested this a bunch of times today, and this fixes the problem for NGO. Now I don't know if this is something caused by EOSNetworkTransport, or a bug within NGO, but this is a fix for any other developer out there until this gets fixed internally, whether it is in this plugin or NGO.

I'm assuming that you mean EOSTransport? Can you point me to where you're thinking it intersects with the DisconnectEventHandler?

[nitrocss]

It seems that the problem is that the DisconnectEventHandler for some reason calls the disconnect twice, and it returns id 0 most probably because it's a default value when it fails to resolve id. However, we tested this a bunch of times today, and this fixes the problem for NGO. Now I don't know if this is something caused by EOSNetworkTransport, or a bug within NGO, but this is a fix for any other developer out there until this gets fixed internally, whether it is in this plugin or NGO.

I'm assuming that you mean EOSTransport? Can you point me to where you're thinking it intersects with the DisconnectEventHandler?

At first look:
in Netcode for gameobjects, in NetworkConnectionManager, in Initialize()
NetworkManager.NetworkConfig.NetworkTransport.OnTransportEvent += HandleNetworkEvent;

then

internal void HandleNetworkEvent(
   NetworkEvent networkEvent, 
   ulong transportClientId, 
   ArraySegment<byte> payload, 
   float receiveTime)
{
   switch (networkEvent)
   {
       case NetworkEvent.Disconnect:
           DisconnectEventHandler(transportClientId);
       break;
   }
}

client id seems to be provided by the EOSTransport. Again, I didn't spend too much time looking into this, but since it was something I couldn't reproduce with Unity Transport, I think there must either be too many transport events being called, or the ID is being returned wrong by EOSTransport.

[paulhazen]

Some other details that would be good to have:

• What version of Unity are you using?
• What version of NetCode are you using?
• What operating system are you using?
• What version of the plugin are you using?

[nitrocss]

• Unity 2022.3.12f1
• Netcode for Gameobjects - 1.7.1
• Windows 10
• Newest stable EOS plugin - 3.0.3

[paulhazen]

Ah - I think I see the problem. We don't currently support that version of Netcode, which is something we will work on providing support for in the near future. As it is - there is a huge difference between Netcode v1.0.2 (which is the one that we use in our demo project), so we have some catching up to do.

For the time being, since it is not something we currently support, I'm going to close this issue, but I'm fitting it into our priorities. I'm going to also add the "unresolved" label to this issue, as that is how we track issues that fall into this category.

Added to my list of tasks :)

[paulhazen]

@nitrocss In retrospect, it seems more appropriate to move this to a discussion, so we can continue to help find a work-around between now and when we've implemented support for the newer version of Unity and the newer version of Netcode.

You have alluded to a few things that have served as stop-gap solutions - do those satisfy your requirements for the time being, or are there still wrinkles that we can help you iron out?