I am developing a game with netcode for gameobjects and i am using Unity Transport. After making the game encrypted (wss), the server crashes when the client exits the game.
Unity editor version: 2022.3.5f1
Netcode for GameObjects version: 1.5.1
Unity Transport version: 2.0.2
Also, how is the client exiting the game? Is it a clean disconnect (calling the NetworkManager.Shutdown method)? Is the client just closing the application? What platform is the client on?
Server Platform: Linux
Client Platform: WebGL
Connection Type: Direct IP Connection(with wss://domain:port with A Record)
I get the error when the user just closes the application directly.
If you’re able to make a server build with Burst disabled (you can do that in the Burst AOT settings), that might produce a more interesting stack trace. I’m thinking the one in your original message might be bad in some way since that unitytls_client_get_ciphersuite_cnt function isn’t being called by the TLS send job.
Looking at the code on my end, I can see a scenario where a segfault would occur in the TLS layer if the connection was suddenly closed while there were packets pending to be sent.
I’ll make the fix in the transport package and try to get a release going, but in the meantime if you’re willing to use a customized version of the transport package (here are instructions to do so), you could patch it yourself. You’d need to add the following code at line 519-ish of Runtime/Layers/TLSLayer.cs:
var clientPtr = ConnectionsData[connectionId].UnityTLSClientPtr;
// Add these lines:
var connectionState = Connections.GetConnectionState(connectionId);
if (clientPtr == null || connectionState != NetworkConnection.State.Connected)
{
packetProcessor.Drop();
continue;
}
Ah yes my apologies. I had forgotten that the connection list wasn’t passed to the send job in the TLS layer. You can remedy this by adding this line at the top of the SendJob structure (line 495-ish):
public ConnectionList Connections;
And then this line in the creation of the SendJob instance (line 565-ish):
Are you seeing the issue with 1.4.0? The error reported here was for code that only exists in 2.X. I would not expect this error to occur in the 1.X version of UTP. If it does, we’d need a detailed stack trace to investigate what’s happening.