Managing Reliable Versus Unreliable RPC Delivery

In this lesson, you will learn how to balance network stability and performance by choosing between reliable and unreliable Remote Procedure Calls (RPCs).

The Core Trade-off

When calling an RPC, you must decide whether the packet must reach its destination or if it is acceptable to lose it.

An Unreliable RPC is "fire and forget." It is sent once and assumes the network will deliver it. If the packet is lost due to packet loss or congestion, the engine does not attempt to resend it. This makes it incredibly efficient for high-frequency data, such as a player’s rotation or mouse input, where a lost packet is immediately superseded by a newer, fresher update anyway.

A Reliable RPC, conversely, adds a layer of acknowledgment. If the packet doesn't reach the client or server, the engine automatically queues it to be retransmitted until receipt is confirmed. While this guarantees the event occurs, it is expensive; if a reliable connection is blocked (e.g., due to packet loss), it can create a "head-of-line blocking" scenario where subsequent packets are held back until the missing one is successfully re-sent.

When to Choose Which?

• Use Reliable for critical state changes that must happen exactly once. Examples include ServerRPC_GrantInventoryItem, MulticastRPC_PlayGameOverSequence, or ClientRPC_NotifyMatchResult. If these are missed, the game state becomes desynchronized or broken.
• Use Unreliable for "streamed" data that updates constantly. Examples include MulticastRPC_UpdateVFXPosition for a moving projectile or ServerRPC_SendInputAxis.

Consider this implementation snippet:

// Critical: Must be received for logic consistency
UFUNCTION(Server, Reliable)
void Server_PurchaseItem(int32 ItemID);

// Non-critical: If one update is lost, the next frame will correct it
UFUNCTION(Server, Unreliable)
void Server_UpdateLookRotation(FRotator NewRotation);

If you mark everything as Reliable, you risk flooding the connection buffer and increasing latency for all players. Conversely, marking critical logic as Unreliable leads to "lost" gameplay actions that leave players frustrated. Always prioritize bandwidth for essentials and let high-frequency updates be ephemeral.

Key Takeaway: Use Reliable RPCs for critical, discrete game events to ensure integrity, and use Unreliable RPCs for high-frequency, ephemeral data to preserve bandwidth and reduce latency.