Reliable vs. Unreliable RPC performance and ordering

Development Programming & Scripting C++
, , , , ,
1

Hello,

I had a couple of general questions about reliable vs. unreliable RPC behavior.

First regarding latency - How does UE4 handle resending reliable RPCs? Is it similar to TCP where the recipient requests a resend? Should we expect greater latency with reliable RPCs? Are there other net performance considerations?

And following from that, is the performance of an unreliable RPC affected by making a reliable RPC on the same frame? ie. Do reliable and unreliable RPCs get added to the same bunch? Would the performance of unreliable RPCs be affected if a reliable RPC is made the same frame?

Lastly, is ordering of unreliable and reliable RPCs guaranteed for the same frame? ie. If I call

SomeActor::Tick()
{
    ReliableRPC();
    UnreliableRPC();
}

will I be guaranteed to receive the ReliableRPC() first?
What if I made the calls on separate frames?

// frame 1
SomeActor::Tick()
{
    ReliableRPC();
}

// frame 2
SomeActor::Tick()
{
    UnreliableRPC();
}

Is it possible to receive the UnreliableRPC() first?

Thank you,
-Chris.

2

First regarding latency - How does UE4
handle resending reliable RPCs? Is it
similar to TCP where the recipient
requests a resend? Should we expect
greater latency with reliable RPCs?
Are there other net performance
considerations?

Yes, we resend reliable RPC’s. Latency can be greater if there is large amount of packet loss, since a lost packet will interrupt the stream while waiting for the missing ones to be resent. If there is little to no packet loss though, it shouldn’t add any latency.

And following from that, is the
performance of an unreliable RPC
affected by making a reliable RPC on
the same frame? ie. Do reliable and
unreliable RPCs get added to the same
bunch? Would the performance of
unreliable RPCs be affected if a
reliable RPC is made the same frame?

Yes, unreliable RPC’s may get merged with reliable RPC’s (so would inherit the performance, though that is minimal without packet loss). In this case, it will arrive on the same frame as the reliable RPC, and in the same order sent. But this behavior cannot be expected, so it’s safer to assume the unreliable RPC might arrive before or after the reliable RPC.

Lastly, is ordering of unreliable and
reliable RPCs guaranteed for the same
frame? ie. If I call

No, as mented above, it’s safer to assume the unreliable RPC might arrive before or after the reliable RPC, regardless if made on the same frame or separate.

Hope this helps, let me know if you have more questions!