Feedback [RESOLVED] [Unity.Transport] Expose Transport Connection Disconnect *Cause*

Context
In Unity.Transport v3.1, there are 3 places where the netcode logic can raise a Disconnect event (via

AddDisconnection

, NetworkDriver.cs:937):

1. In the handler of a

   UdpCProtocol.Disconnect

   event, which represents a deliberate, intentional disconnect.
2. Inside

   CheckTimouts

   , which represents failing to establish a connection with the server.
3. Also inside

   CheckTimouts

   , which represents an established connection timing out.

Problem
I would like to perform different logic based on whether or not a client disconnected via timeout, or disconnected intentionally (i.e. deliberately), or failed to connect at all.

For example, communicating the quit differently to the remaining players:
"Niki quit." vs "Niki lost connection."

Ideal solution
Unity.Transport would expose a

LastDisconnectCause

byte enum inside the internal

Connection

struct (NetworkDriver.cs:272) which is queryable via something similar to

GetConnectionState

.

This is the best solution IMHO because it allows the enum to be set at the locations above, which means we don't need to infer or guess. 100% concrete.

Less ideal solution that saves a little memory
Unity.Transport would contain getters for the underlying

Connection

struct to allow us to determine for ourselves what the cause was by querying

LastAttempt 

and

Attempts

, similarly to how it exposes the

NetworkConnection.State

via

GetConnectionState

.

Either way, I wouldn't mind upgrading to 4.x for this change, especially because you recently added support for fragmentation (thank you!).

Cheers!

 

Right now the only way for you to do this is to send 2 messages on disconnection. One event of type data which has a disconnect message, reason or info and then the next one of type disconnect which disconnects the connection.
Then when you pop the events and you get the data event with the disconnect info and the disconnect event you know it was a user disconnect, if you only get the disconnect event you know it was a timeout.

The ideal solution in my opinion would be to add a data field to the disconnect event which has a disconnect reason which you can check when you pop the event. Maybe we get something like this in a future version.

 

@FakeByte Yeah it's absolutely a problem I can solve on my end, I just shouldn't have to because the information DOES exist - it's just not exposed.

Using the concrete info from the transport internals will remove complexity from disconnects, which is appreciated.

 

Its still in preview, we can still hope that those improvements will still come later after the essential stuff is done. I implemented my own INetworkInterface and noticed how unflexible the network driver is at the moment.

 

Resolved in 0.6.0, thanks guys!
https://docs.unity3d.com/Packages/com.unity.transport@0.6/changelog/CHANGELOG.html