UnityTransport add a heartbeat feature so clients dont disconnect after not sending data for a while.

[ikomhoog]

Is your feature request related to a problem? Please describe.
TLDR: I was having trouble with inputs and ownership, which caused me not to send any updates/RPCs, this causes the client to disconnect.

I was just testing with an almost empty scene and just figuring out how to get the PlayerInput component working with network spawning and ownership.
As this was my first time messing with both of them lots of things were wrong.
I then noticed that after just over 30 seconds my client disconnects.
Thinking I messed something up I went back to a previous commit and tested the same thing, I disconnected.
Going back to my latest working version in which I have correctly used the PlayerInput I messed around with keeping my character moving, and I didn't disconnect.
Then I stopped moving and 30 seconds later I disconnected

Describe the solution you'd like
I would like a heartbeat feature in the UnityTransport so the disconnect doesn't happen.

Describe alternatives you've considered
I have considered writing a heartbeat script myself (just a simple timer that calls an empty ServerRPC or something) and adding it to the NetworkManager GameObject.
But it would be a lot cleaner to have it in the Transport.

Additional context
Disconnecting in this way also isn't clean.
I have not yet made a disconnect function so I don't know what it normally does.
Here are the logs that I got:

ObjectDisposedException: The Unity.Collections.NativeList`1[Unity.Networking.Transport.NetworkDriver+Connection] has been deallocated, it is not allowed to access it
Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckReadAndThrowNoEarlyOut (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) (at <41d34619c06946aebeba0ca1ee6d765b>:0)
Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckReadAndThrow (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) (at <41d34619c06946aebeba0ca1ee6d765b>:0)
Unity.Collections.NativeList`1[T].get_Length () (at Library/PackageCache/com.unity.collections@1.0.0-pre.5/Unity.Collections/NativeList.cs:232)
Unity.Networking.Transport.NetworkDriver.GetConnection (Unity.Networking.Transport.NetworkConnection id) (at Library/PackageCache/com.unity.transport@1.0.0-pre.6/Runtime/NetworkDriver.cs:1307)
Unity.Networking.Transport.NetworkDriver.GetConnectionState (Unity.Networking.Transport.NetworkConnection con) (at Library/PackageCache/com.unity.transport@1.0.0-pre.6/Runtime/NetworkDriver.cs:1087)
Unity.Netcode.UnityTransport.ProcessEvent () (at Library/PackageCache/com.unity.netcode.adapter.utp@1.0.0-pre.2/Runtime/UnityTransport.cs:411)
Unity.Netcode.UnityTransport.Update () (at Library/PackageCache/com.unity.netcode.adapter.utp@1.0.0-pre.2/Runtime/UnityTransport.cs:479)

At first, I thought that these caused the disconnection, but it turns out that it was a timeout.

[davidrtho]

Looks like the functionality is there, just missing a value in the pre-processor directive.

        public void CreateDriver(UnityTransport transport, out NetworkDriver driver, out NetworkPipeline unreliableSequencedPipeline, out NetworkPipeline reliableSequencedPipeline, out NetworkPipeline reliableSequencedFragmentedPipeline)
        {

#if UNITY_EDITOR || DEVELOPMENT_BUILD
            var netParams = new NetworkConfigParameter
            {
                maxConnectAttempts = NetworkParameterConstants.MaxConnectAttempts,
                connectTimeoutMS = NetworkParameterConstants.ConnectTimeoutMS,
                disconnectTimeoutMS = NetworkParameterConstants.DisconnectTimeoutMS,
                heartbeatTimeoutMS = NetworkParameterConstants.HeartbeatTimeoutMS, // this is left out
                maxFrameTimeMS = 100
            };

            var simulatorParams = ClientSimulatorParameters;
            transport.m_NetworkParameters.Insert(0, simulatorParams);
            transport.m_NetworkParameters.Insert(0, netParams);
#endif

[will-mearns]

This appears to be a bug.

[JesseOlmer]

This was fixed in 1.0.0-pre.3. #1314. Please re-open if you're still encountering the issue after trying that version (and include the environment section of our bug template so we have details about what version you're using).