Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

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

Discussion in 'Multiplayer' started by NWalker_FGOL_Ubisoft, Sep 14, 2020.

  1. NWalker_FGOL_Ubisoft

    NWalker_FGOL_Ubisoft

    Joined:
    Aug 10, 2015
    Posts:
    25
    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!
     
    Last edited: Sep 14, 2020
  2. FakeByte

    FakeByte

    Joined:
    Dec 8, 2015
    Posts:
    147
    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.
     
  3. NWalker_FGOL_Ubisoft

    NWalker_FGOL_Ubisoft

    Joined:
    Aug 10, 2015
    Posts:
    25
    @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.
     
  4. FakeByte

    FakeByte

    Joined:
    Dec 8, 2015
    Posts:
    147
    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.
     
  5. NWalker_FGOL_Ubisoft

    NWalker_FGOL_Ubisoft

    Joined:
    Aug 10, 2015
    Posts:
    25