From aa699ce8c7287ff4e40e825591dc848bad05dc77 Mon Sep 17 00:00:00 2001 From: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com> Date: Fri, 13 Aug 2021 11:34:57 -0400 Subject: [PATCH 1/2] adding more details to multiprocess readme --- .../Runtime/MultiprocessRuntime/readme.md | 36 +++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md b/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md index 7a7e8ea8fc..c6bbd543a4 100644 --- a/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md +++ b/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md @@ -196,10 +196,42 @@ Note that performance tests should be run from external processes (not from edit ## How it's done ### Multiple processes orchestration -The test runner executes the main node's tests. The tests are in charge of launching their needed workers. + +Test code and host code execute in the same process: When writing play mode tests, Unity will start a unity environment for that test, including game loop, scene, object hierarchy, all that fun stuff. This means the test itself has access to everything other unity scripts would have access to. At test startup, the test will ask unity to switch scene to MultiprocessTestScene containing a GameObject already placed in that scene called TestCoordinator . The test will callStartHost that will listen for connections, still all in the same process. +Once that’s done, that same test will then spawn new client processes. These clients will also start with that MultiprocessTestScene loaded at startup, also containing a TestCoordinator . These client side TestCoordinators will detect they are clients (using command line arg) and instead of calling StartHost will call StartClient . This is where new code to specify the IP to connect to would stand (the lines I sent you). +A good way I could have clarified that code is to separate TestCoordinator into TestCoordinatorClient and TestCoordinatorServer thinking of it. Right now TestCoordinator code does both. +Once the connection is established (tests yield wait for connection in Setup code), then the tests can start sending RPCs to each other. +Like Jeff said, the test (that’s server side) will call multiple TriggerActionIdClientRpc . This will trigger these actions on all clients. The clients execute their test code, then answer back with ClientFinishedServerRpc. +Once all the tests are done exchanging commands, a final RPC CloseRemoteClientRpc is called to tell the clients they are done. +If that RPC fails to send for some reason, clients also have a keep alive that tells them to self destroy when it expires. +If you look at the “how it’s done” section in the multiprocess readme.md testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md there’s a few drawings to explain that flow. + +So: +Editor +- Run tests +- Run host code +- Launches builds +Separate build +- Runs client RPCs that execute test code, not the tests themselves + + +Now just to bake your noodles a bit more, Unity will take an additional step before launching these steps. The above is true if you launch these tests from the editor. If you launch these tests in a separate player, Unity in the background will create a separate process for that player. That player will then connect using a plain tcp connection to the editor to report back on its test results. This is important to know if you want to have the test/host part launch on different platforms like mobile. + +So the above would become +Editor +- Launches test player on platform +Test player +- Run tests +- Run host code +- Launches builds +Separate build +- Runs client RPCs … + With the bokken integration, we'll need to be careful about ressource contention at Unity, these tests could be heavy on ressources. Tests when launched locally will simply create new OS processes for each worker players. + + ![](readme-ressources/OrchestrationOverview.jpg) *Note that this diagram is still WIP for the CI part* ### Bokken orchestration @@ -217,4 +249,4 @@ During test execution, the main node's step will call an RPC on clients to trigg # Future considerations - Integrate with local MultiInstance tests? -- Have ExecuteStepInContext a game facing feature for sequencing client-server actions? \ No newline at end of file +- Have ExecuteStepInContext a game facing feature for sequencing client-server actions? From f6ccb7c0d70cc073810b89b5a0cbc7dbaa54eab2 Mon Sep 17 00:00:00 2001 From: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com> Date: Fri, 13 Aug 2021 14:12:01 -0400 Subject: [PATCH 2/2] removing silly error --- testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md b/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md index c6bbd543a4..b8ed53c797 100644 --- a/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md +++ b/testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md @@ -201,7 +201,7 @@ Test code and host code execute in the same process: When writing play mode test Once that’s done, that same test will then spawn new client processes. These clients will also start with that MultiprocessTestScene loaded at startup, also containing a TestCoordinator . These client side TestCoordinators will detect they are clients (using command line arg) and instead of calling StartHost will call StartClient . This is where new code to specify the IP to connect to would stand (the lines I sent you). A good way I could have clarified that code is to separate TestCoordinator into TestCoordinatorClient and TestCoordinatorServer thinking of it. Right now TestCoordinator code does both. Once the connection is established (tests yield wait for connection in Setup code), then the tests can start sending RPCs to each other. -Like Jeff said, the test (that’s server side) will call multiple TriggerActionIdClientRpc . This will trigger these actions on all clients. The clients execute their test code, then answer back with ClientFinishedServerRpc. +The test (that’s server side) will call multiple TriggerActionIdClientRpc . This will trigger these actions on all clients. The clients execute their test code, then answer back with ClientFinishedServerRpc. Once all the tests are done exchanging commands, a final RPC CloseRemoteClientRpc is called to tell the clients they are done. If that RPC fails to send for some reason, clients also have a keep alive that tells them to self destroy when it expires. If you look at the “how it’s done” section in the multiprocess readme.md testproject/Assets/Tests/Runtime/MultiprocessRuntime/readme.md there’s a few drawings to explain that flow.