Skip to content

refactor: Remove SIPTransport and replace it with UnityTransport #1870

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 30 commits into from
Apr 14, 2022

Conversation

NoelStephensUnity
Copy link
Collaborator

This removes the SIPTransport from our integration tests and replaces it with UnityTransport.
This includes several integration test refactors, and some minor fixes to bugs that were not detected under SIPTransport.

MTT-3016

Changelog

  • Changed: NetcodeIntegrationTestHelpers to use UnityTransport.
  • Removed SIPTransport from integration tests.

Testing and Documentation

  • Includes adjustments to integration tests.

0xFA11 and others added 22 commits April 4, 2022 16:46
This fixes the timing issues with the MessageOrdering.SpawnRpcDespawn integration test.
This also includes a minor update to NetcodeIntegrationTestHelpers (destroy as opposed to destroy immediate).
This fixes the issue with MultiClientConnectionApproval.ClientConnectedCallbackTest failing when using UTP as opposed to SIP.
Fixed issue with ConnectionApprovalHandler's prefab getting destroyed when a client was disconnected.
Applied same fix to the NetcodeIntegrationTest when creating a prefab.

Also fixing issue with NetworkManager spewing spam messages if the NetworkConfig.ConnectionApproval is set but there is no ConnectionApprovalCallback assigned.  Adjusted it to make sure it is either the Server or Host that this applies to, but not a client.
This fixes the ConnectionApprovalMismatchTest issue that caused it to fail with UTP.
Switching over to client notifications (i.e. the server detects the mismatch and disconnects the clients, we want to make sure the clients received the disconnection notification).
Global fix for teardown and NetworkObject destroying....make sure the server is the NetworkManagerOwner before destroying it.
Some NetcodeIntegrationTest adjustments to handle the switch over to UTP.
Fixes issues with NetworkObjectParentingTests (increased wait time between changes to 1 full Network Tick).
Also the recent NetcodeIntegrationTest updates helped fix some of the issues with NetworkObjectParentingTests.
Fixes the issue with NetworkSpawnManagerTests.TestConnectAndDisconnect.
Switching to UnityTransport exposed a potential bug where the server disconnects a client while the client is still processing a SceneEventType.Synchronize message which by the time the client processes this it has already sent the SceneEventType.SynchronizeComplete message back to the server that *could* attempt to send a resynchronization message where the MessageSystem will crash because the m_SendQueues entry for the now disconnected client no longer exists.
Added some additional UnityTransport settings for payload size, send queue size, and reducing the connection attempts and time out to connect per attempt.

Added the ability to specify whether you want the server or clients to be instantiated first (see comments under NetcodeIntegrationTest.m_CreateServerFirst for further explanation).
Removing UNet and just using UTP.
Reducing the timeout period so it doesn't take over 60 seconds to timeout.
Fixes timing issues with this test that is causing it to not passing when using UTP.
Fixed timing issues exposed when using UTP.
This fixes an issue when I originally switched it to be the server as the default NetworkManager to be instantiated when using NetcodeIntegrationTestHelper.Create.  This sets the, recently updated NetcodeIntegrationTest  m_CreateServerFirst, clients to instantiate before the server (needed for in-scene objects)
This test requires the clients to be instantiated before the server.
MTT-3016
Changelog entries.
@NoelStephensUnity NoelStephensUnity requested a review from a team as a code owner April 12, 2022 19:07
Comment on lines +1749 to +1751
// Check to see if the client needs to resynchronize and before sending the message make sure the client is still connected to avoid
// a potential crash within the MessageSystem (i.e. sending to a client that no longer exists)
if (sceneEventData.ClientNeedsReSynchronization() && !DisableReSynchronization && m_NetworkManager.ConnectedClients.ContainsKey(clientId))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +82 to +88
/// <summary>
/// Set this to false to create the clients first.
/// Note: If you are using scene placed NetworkObjects or doing any form of scene testing and
/// get prefab hash id "soft synchronization" errors, then set this to false and run your test
/// again. This is a work-around until we can resolve some issues with NetworkManagerOwner and
/// NetworkManager.Singleton.
/// </summary>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you mind elaborating a little more? what's going on here?

Copy link
Collaborator Author

@NoelStephensUnity NoelStephensUnity Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a little complicated, but it has to do with our integration tests running in the same thread, how we populate newly loaded (not yet "spawned") in-scene placed NetworkObjects, and NetworkObject.NetworkManager referencing NetworkManager.Singleton if NetworkObject.NetworkManagerOwner is null.

  • Same Thread: In several places we check to make sure the NetworkObject.NetworkManager is the "right one" for the NetworkManager context (i.e. NetworkObject.NetworkManager == NetworkManager)
  • Populating In-Scene Objects: This checks to make sure the NetworkSceneManager.m_NetworkManager is the same as the NetworkObject.NetworkManager before adding it to the ScenePlacedObjects list.
  • Default NetworkManager: This happens to be NetworkManager.Singleton that is set upon the first NetworkManager being instantiated.

So, under some conditions you might want NetworkManager.Singleton to be the server and under other conditions you might want it to be a client. If you are loading a scene with in-scene placed NetworkObjects, then you will want the NetworkManager.Singleton to be the first client instantiated in order to properly synchronize/find the in-scene placed NetworkObjects (which are loaded by the server and not loaded by the client since they share the same scene space).

If you want more details feel free to DM me in slack... really we need to handle in-scene placed NetworkObjects better... like that "pre-rfc" document outlines.

var allHandlersDestroyed = false;
var waitForTick = new WaitForSeconds(1.0f / m_ServerNetworkManager.NetworkConfig.TickRate);

while (!(allHandlersSpawned && clientCountReached && allHandlersDestroyed))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add @ShadauxCat as a reviewer to review changes around these tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(just in case)

@NoelStephensUnity NoelStephensUnity marked this pull request as draft April 12, 2022 19:41
This resolves the issues with tools integration tests and switching over to UnityTransport.
@NoelStephensUnity NoelStephensUnity marked this pull request as ready for review April 12, 2022 20:00
@NoelStephensUnity NoelStephensUnity requested a review from a team as a code owner April 12, 2022 20:00
Copy link
Contributor

@0xFA11 0xFA11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm 🚀

NoelStephensUnity and others added 4 commits April 12, 2022 15:15
Co-authored-by: Fatih Mar <mfatihmar@gmail.com>
Co-authored-by: Fatih Mar <mfatihmar@gmail.com>
The following fixes some edge-case timing related issues that are being exposed in Yamato where it might take longer than 1 network tick depending upon the virtual machine's current load.  Primarily, the majority of the fixes are handled by just waiting for the condition or timing out.
the time out was never yielding and causing issues on PS4/
Copy link
Contributor

@Rosme Rosme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the changes in the tests integration stuff as well as whatever may touch the tools.

NoelStephensUnity and others added 2 commits April 13, 2022 09:33
Removing some code that didn't need to make it into this PR.
@NoelStephensUnity NoelStephensUnity merged commit 6555a1e into develop Apr 14, 2022
@NoelStephensUnity NoelStephensUnity deleted the refactor/kill-sip-use-utp branch April 14, 2022 02:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants