RPCs are not affected by Simulator Tools artificial network conditions

[elton-okawa]

Describe the bug
RPC calls are not affected by Simulator Tools artificial network conditions

To Reproduce

1. Clone this repository
2. Open Netcode -> Simulator Tools
3. Set delay to 200 (we can leave others the default value)
4. Open ParrelSync -> Clones Manager
5. Click Add new clone
6. After a while, there'll be a option called Open in new Editor click on it
7. In this new editor start the game and select Server
8. In the previous editor also start the game and select Client
9. View the client editor calculated ping

Actual outcome
RPC based ping is not roughly equals configured network conditions

Expected outcome
RPC based ping should be roughly equals configured network conditions

Screenshots
The following screenshot shows using client/server editor delay of 200 and 0 in other options

Network Var Ping

1. client sends rpc with time t1 = current time
2. server changes Network Var with received time t1
3. client receives the Network Var update with t1
4. client stores the difference currentTime - t1
5. client calculates mean RTT
6. client updates text
7. Repeat 1 to 6

Rpc Ping

1. client sends rpc with time t1 = current time
2. server reply rpc with received time t1
3. client receives the rpc with t1
4. client stores the difference currentTime - t1
5. client calculates mean RTT
6. client updates text
7. Repeat 1 to 6

Environment

• OS: Windows 10
• Unity Version: 2020.3.12f1
• Netcode Version: 1.0.0-pre.3
• Transport for Netcode Version: 1.0.0-pre.3

[aazzolini]

I'm experiencing the same issue and it's actually making it hard to iterate on my netcode. I am basically deploying my server to EC2 as the only way to simulate these latency conditions.

[0xFA11]

https://jira.unity3d.com/browse/MTT-1907

[simon-lemay-unity]

Fixed (inadvertently) by PR #1512, which was backported to release/1.0.0 with #1515. The fix will be available in release 1.0.0-pre.4 of the adapter (com.unity.netcode.adapter.utp).

The repro project forces the ping RPCs to use the unreliable delivery method. In the adapter, this caused the traffic to be sent through the null pipeline, which is unaffected by simulator parameters. #1512 made it so that unreliable traffic is now fragmented too, which means it goes through a different pipeline (and this one just happens to support the simulator parameters). So now all traffic (no matter the delivery method) should be affected by the simulator parameters.