Unity-Technologies
Improve Disconnect Logging for Clients
Is your feature request related to a problem? Please describe. In our project, we have a pretty simple problem: why has a client been disconnected? Disconnects can happen for a variety of reasons, ranging from timeouts, bad netcode configurations, or version mismatches. Having inspected the code in the ConnectionRequestMessage, its clear that the server knows why a client is disconnected. However, this info is never shared with the client, leading to confusion about why the user cannot join the server. Given that we operate in a cloud environment, with the server running in a container, we need some way to inform the clients why they cannot connect.
Describe the solution you'd like Ideally, we would like to have some kind of enum that is pass in with the DisconnectClient event that identifies why this is occurring. Currently, there is 'string reason = null' that is passed, but almost all of netcodes internal functions leave this as null. For example, the Deserialize function from ConnectionRequestMessage knows that a client has a version mismatch. However, it returns the default 'reason' for said disconnect, making any logic related to version mismatches impossible.
Describe alternatives you've considered We have considered implementing our own version checks via the ConnectionApproval systems byte array payload. While that would solve this particular issue, it wouldn't help with other internal failures that happen after a client is connected (Say, failure during scene sync).
Hi @Reag,
What version of NGO are you currently using? The most recent version does have improved disconnect reasons.
Heya @NoelStephensUnity ,
We're running on NGO 2.7.0. I have noticed improved logging for many disconnect cases, but the one that prompted this feature request (protocol version mismatch) is not one of them. I currently have a task to set up an exit code for if someone attempts to join one of our cloud rooms with an older version, but I don't have a mechanism to determine why a client disconnected.
Protocol Mismatch occurs before client validation and connection approval, so I cant even send back some custom identifier to let the user know that they have some versioning issue. As far as the client is concerned, the server rejected the connection for no reason.
My ideal solution to this would be to have some disconnect reason enum passed along with the reason string. This would help us immensely in identifying why a client is disconnected :)
@Reag When this happens do you get a NetworkTransport.DisconnectEvents.ProtocolError?
The start of the NetworkManager.DisconnectReason set would follow this format:
[Disconnect Event][Client-{clientId}][TransportClientId-{transportClientId}][{Transport.DisconnectEvent}]
It would look something like:
[Disconnect Event][Client-2][TransportClientId-1783485724][ProtocolError]
If not, then what is the NetworkManager.DisconnectReason set to when this happens?
Are you using UnityTransport? Could you describe which protocol (i.e. UDP, Websocket/TCP, custom, etc) is having the protocol version mismatch?
Sorry for the delay!
From my experience setting up our netcode, we have never had any useful information passed from NetworkManager.DisconnectReason. I made sure that we log any disconnect reason with high priority in our custom logger. However, I have no memory of us ever getting a useful diagnostic message from this field.
I haven not tried connecting directly to the network transport. Ill put some direct log messages there and see if it helps us diagnose whats going wrong when clients try to connect. Given that the transport layer is hidden behind the NGO layer, I didn't think to try directly accessing its events.
We're using UnityTransport for our backing, with either UDP or Websockets depending on our clients requirements. The protocol mismatches are not in and of themselves a problem, as we have different protocol versions for different clients, and don't want them to be able to connect to the wrong servers. Our issue is just detecting such a mismatch in a way we can log it and relay the information to the user.