Hello,
I have a few questions about sequencing and reliability in Netcode.
In the documentation of Netcode, for RPCs, I see the following statement:
in-order reliable RPC execution is guaranteed per NetworkObject basis only
Question #1: Why in-order reliability is not ensured globally?
So far I found that all network objects use a single NetworkPipeline for reliable messages. In a usual flow, RPC messages are sequenced properly on this pipeline. However, RPC messages that are sent while spawning a network object (e.g. in OnNetworkSpawn method), are delayed and sent after “create object” message. In other words, if I have the following code:
public override void OnNetworkSpawn()
{
base.OnNetworkSpawn();
if (IsHost)
{
ThisObjectClientRPC();
OtherObjectThatIsAlreadySpawned.SomeClientRPC();
}
}
The client first receives OtherObjectThatIsAlreadySpawned.SomeClientRPC(), then it receives ThisObjectClientRPC(). And this implies the order is broken. Related to the question above, is this the main reason?
Question #2: To ensure global in-order reliability, I am planning to use unnamed messages or put a restriction on how RPCs are used in my project if the initial synchronization is the only source of problem as mentioned above (only send RPCs after spawning is complete). Do you see any problems with this approach?
Question #3: I see that we are using three pipelines, two for unreliable and one for reliable (see UnityTransport.cs). For some objects I would like to send unreliable messages to clients on each network update (e.g. to update position). However, for certain moments in the game, I would like to send an in-order reliable message (e.g. set the position for resetting the current level). Since unreliable and reliable messages use different network pipelines, even if they are ordered in their own pipeline, ordering between the pipelines is not guaranteed. What is the best approach for solving this problem in Netcode?
Notice that since the order is not guaranteed, the client might first receive the reliable message for resetting the level and update the position. Then the client might receive unreliable position which was sent before resetting the level (outdated position). This could be critical on the client side as it can’t rely on having the correct position during the reset operation. In order to solve this, one could add sequence number to these messages but that would be quite wasteful since the sequence number is already sent for ensuring order in the network pipeline. From what I see the game code is not aware of this sequence number.
Thank you!