Hello,
I have a few questions about execution order on RPC and replication,
1, Will RPC receiving order keep the same as sending? example like below
Server send RPC1, RPC2 to client ActorA, RPC3, RPC4 to client ActorB, what will be the possible order on the client side? can RPC3 come back earlier than RPC1?
2, With the same set of the replication settings, the fieldA and fieldB on single Actor are ordering update, can fieldB update faster than fieldA?
Many thanks.
Hi GollumCN,
As I know the RPCs sent to the same client are guaranteed by order, but not guaranteed for different clients. And replication is not guaranteed either.
I have some interesting found on RPC part, it looks like can not guarantee with multi Actors cross two network machine, this does not happen if you try to run two instance on single machine.
EDITED:
ONLY Reliable RPC’s will truly garauntee order, and ONLY for the same actor. Connections do not matter. Note that they do not neccesarily arrive in order, but they will be processed in order.
Unreliable RPC’s will execute in the order they were called in (since each packet has an ID to identify it’s order) - but only if they do actually arrive, so that’s the crux and probably shouldn’t be relied on so much. I’m not sure if this is true for multicast unreliables since they have some special handling.
Reliable RPC’s cannot be dropped, as if they are dropped the client will be kicked anyway.
Property replication does not garauntee any order, even on the same actor. This is because property replication is lossy, you will not receive every change made to a property, only it’s final state.
Quote from an old document of UDK (UE3):
Within an actor, multiple reliable functions are guaranteed to be called on the remote machine in the same order that they were called on the local machine.
Just FYI. (UDK | FunctionReplication)
@TheJamsh , Thank you, what you saying is exactly the things I learn from my test cases, even the UE source code looks like the RPC message will go to the network layer kind of straightforward, but the result cross two network machine for two Actors are unordered, I didn’t check the network part, I think there is possible more logic in it.
@TIANMIN Thank you, do you have the case for multi Actors?
RPC calls between different actors do not garauntee any order on the receiving end, reliable or not. No exceptions to that rule.
Totally agree, thank you very much for the helps.
Hey could you elaborate on this last part? If I have a replicated property value and only change it once on the server, not continously, is it guaranteed that the changed value will eventually arrive on the clients? Or can this one single change be lost and the clients assume forever that the value was never changed?
As long as the Actor the property belongs to is changed while the Actor was in an active state then it will eventually get replicated to the Client.
So yes you can assume a replicated property change is reliable.
Thank you very much for the clarification!
Does “property replication” mean variable replication (RepNotify)?
Yes (it’s a UPROPERTY, I guess that’s why they used the term property)