Formalizing Rollback Netcodes for Robust and Real-Time Client-Server Architectures

Games based on netcodes are typically built on either a client-server or a peer-to-peer (P2P) architecture, each offering distinct advantages and trade-offs. In the client-server model, a central server manages the game state, processes player inputs, and ensures synchronization across all clients. This strong central authority enhances game integrity by mitigating cheating and maintaining consistency. However, the cost of maintaining a server infrastructure can be prohibitive for some game studios, leading them to prefer a P2P strategy. In contrast, P2P games often designate one player as the host, who acts as a de facto server to manage the game state. While this approach significantly reduces infrastructure costs, it introduces vulnerabilities such as increased susceptibility to cheating, security risks, and heavy dependence on the host’s connection, computing power, and fairness. A few P2P games take a fully decentralized approach, distributing responsibilities across all players’ devices. Although this can improve scalability and minimize infrastructure demands, it often exacerbates issues related to latency, security, and inconsistent gameplay [25]. Since most games relevant to our problem adopt either a client-server model or a P2P model with a host, we assume a client-server architecture in the following discussion.

Netcode is a broad term referring to the systems and algorithms that manage communication between players in online games, ensuring synchronization and responsiveness during gameplay. Two common types of netcodes are widely used: delay-based and rollback [4]. In delay-based netcodes, all players’ inputs are delayed until they are received and processed by all participants, guaranteeing synchronization but often causing noticeable input lag under high latency conditions. Rollback netcodes, by contrast, minimize input latency by executing and rendering player actions immediately on the client’s game state. This significantly enhances responsiveness – and by extension, player immersion – but introduces the risk of temporary desynchronization between clients [2, 15] The latency-based attacks we target in this article (such as DDoS and Lag Switch) are specific vulnerabilities associated with rollback netcodes.

The main advantage of rollback netcodes is their responsiveness to player input. Since they are processed directly by clients and rendered to players (almost) immediately, without waiting for server approval, they are highly responsive. To explain how such a mechanism might lead to desynchronization between clients and servers, we must first delve into the technical details of a typical rollback netcode implementation.

Games operate on a system of ticks, a discrete unit of time during which the game processes updates such as player inputs, physics calculations, and AI behavior. These ticks occur at a fixed rate, measured in ticks per second (TPS), and act as the game’s central clock. For example, a game running at 60 TPS updates the game every 16.67 milliseconds. A higher tick rate offers a smoother gameplay but requires greater computational resources. In a client-server architecture, the server ensures synchronization by standardizing the tick rate across all clients or by allowing varied tick rates but mapping each tick to standardized moves shared between clients. This approach accommodates clients with differing computational power without limiting the faster ones [19]. Crucially, clients send their inputs to the server at the same frequency, and the server manages synchronization. For instance, when the server receives inputs from client A for tick #354, it understands how this aligns with tick #287 of client B, whether or not those inputs have already been received. For the sake of simplicity, we consider in the following, without loss of generality, that the ticks of all clients are synchronized (e.g., Client A #200 ticks matches with Client B #200 ticks).

The server simulates a few ticks behind the clients to handle latency between clients and the server. When a player performs an input, it is immediately processed and rendered locally on the client’s next tick. At the same time, the client sends this input to the server. The server integrates the received input into its simulation for the corresponding tick and later sends back its authoritative version of the game state to the client. If the server’s state matches the client’s local simulation, no correction is needed. However, if a significant discrepancy is detected, the client must acknowledge that its simulation for the affected tick was incorrect and re-simulate the current game state using the corrected data from the server.

Figure 1 illustrates an example of a flow of messages between one client and the server: The client ($C$) sends its input to the server ($S$) every tick. The inputs allowed are $\{-1,0,+1\}$. ① At $t$, the player is in state $(0)$ (for both client and server) and plays the input $+1$ for the tick $t$, which locally changes its state from $(0)$ to $(1)$. The message carrying this input arrives at the server before the server reaches the $t$ state. The server accepts the input and changes at $t$ the authoritative state of the game and sends this state to the client. ② Between $t$ and $t+1$, the client plays a wrong input (+10) that changes its local state to (11). ③When the server reaches the tick $t+1$ after receiving the wrong input, it refuses this input by computing an in-between value (2). Note that how the server refuses a value is a developer’s choice (it could also have stayed in state (1), for instance). ④ When this corrected state reaches the client (just after its $t+5$), the client rolls back by correcting its state of $t+1$ by $(2)$ and replays the inputs it has played by then ($(2)+1+1+1+0$), computing a new state (5). ⑤Then, due to a latency issue, the input of $t+2$ sent by the client arrives after the server reached its $t+2$ state, leading the server to wait (here one tick) to simulate its $t+2$ state, increasing the delay between the client’s simulation and the server’s simulation.

To compute its authoritative state, the server waits to receive inputs from all clients. This makes the server’s simulation delay highly sensitive to network latency. In most games, there is a maximum delay threshold that defines how long the server will wait. If the delay reaches this threshold and some inputs are still missing, the server predicts them, often by assuming that the new input is the same as the previous one, and proceeds to simulate the game using this predicted data. Importantly, these predicted inputs are treated as authoritative, as they are used to update the official game state.

The further behind the server is in its simulation, the greater the risk of desynchronization between the server and clients, leading to an increased likelihood of rollbacks on the client side. The degree of delay in the server’s simulation depends on the quality of the connection with each client: with a fast and stable connection, the server stays only a few ticks behind; with slower or unstable connections, it delays simulation further, up to the maximum threshold. This threshold varies significantly across games, even within the same genre, and can range from a few milliseconds to several seconds. The implications of choosing this threshold are discussed in more detail in Section 5.3.

An essential characteristic of rollback netcode is that each client perceives other players’ actions exclusively through the authoritative state provided by the server. Consequently, a client observes its own actions ahead of the server (which runs a few ticks behind) and perceives opponents’ actions with additional delay, since their inputs must first transit through the server. This results in a persistent desynchronization among clients: no two clients ever render exactly the same game state. In this sense, the problem strongly diverges from the classical State Machine Replication problem [5], as consensus among states is never reached. Moreover, to preserve immersion, the server strives to accept actions as soon as they are valid in the client’s local view. This approach, unfortunately, might lead to conflicts in case of incompatible concurrent updates, and cause rollbacks on clients.

Figure 2 illustrates such a semantic desynchronization in an online shooting game with two players ($C^1$ and $C^2$) at tick $t$. In $C^1$’s view, actions are observed in advance of the server state, so $C^2$ appears in an outdated position and $C^1$ is allowed to shoot. In contrast, $C^2$’s local view places itself ahead of the server state, safely hidden behind an obstacle, and thus out of $C^1$’s line of fire. Importantly, the server validates $C^1$’s shot, since it is consistent with $C^1$’s perceived game state. Without this mechanism, players would need to aim at where opponents will be in the server’s state, a latency-dependent guess, breaking immersion, as shooting directly at the target would no longer be reliable.

This divergence of views is intrinsic to rollback netcode. In practice, under normal latency conditions, such semantic desynchronization remains imperceptible to human players. However, adversarial conditions such as DDoS or LagSwitch attacks can amplify desynchronization, exploiting the immersion requirement and producing observable semantic conflicts, thereby granting an advantage to attackers. Consequently, in the remainder of this paper, the term immersion is used to denote the formal notion of semantic consistency among clients, particularly with respect to avoiding rollbacks that could compromise this consistency.

The Lag-Switch attack exploits the immersion requirement in the following way: the attacker uses a physical or software switch to momentarily cut the connection between its client and the server at will. From the server’s perspective, as long as this interruption is brief (depending on the max-delay threshold), it appears indistinguishable from a temporary spike in latency. During this disconnection, the attacker can freely perform special actions without interference since it no longer receives updates from the server about other players and thus perceives other players as inactive. Meanwhile, other clients remain unaware of the attacker’s actions until the connection is restored.

Once the attacker reconnects and the delayed packets are delivered to the server, these actions are accepted since they are valid in the attacker’s view and incorporated into the authoritative game state that the server sends to all clients. This leads to rollbacks on other clients, often breaking immersion.

A Distributed Denial-of-Service (DDoS) attack is a coordinated effort to disrupt the normal operation of a targeted server, service, or network by overwhelming it with a massive volume of traffic originating from multiple sources [28, 18, 21]. Often part of a botnet composed of compromised devices, these sources generate traffic at a scale that makes it difficult to distinguish legitimate requests from malicious ones, thereby complicating mitigation efforts. In the context of online gaming, DDoS attacks can be performed by an attacker to cut/slow down the latency between a victim client and the server. During the DDoS, the attacker can perform actions that make it gain some advantages while being sure that the victim cannot perform counteractions since the victim doesn’t see its actions due to high delay/loss of the server’s authoritative states.

If well-performed, both attacks are indistinguishable from each other and/or undetectable from natural latency jitter, because of natural network latency variations.

We introduce two update functions that aim to be as general as possible. Those functions compute the new game state depending on the player’s actions. The two functions have the same purpose: computing the next game state on replicas. We note $U_c$ the update function used by the clients, and $U_s$ the update function used by the server (two functions are necessary, although they have the same purpose, because they do not have the same signature/domain definition). Crucially, both functions are deterministic: identical inputs always produce identical outputs.

The $U_c$ update function takes as input a state, usually the last received from the server, and a subsequence of local input (can also be mathematically seen as a polynomial of the local inputs), usually corresponding to the last performed local input since the tick corresponding to the state of the first parameter. The output of $U_c$ is then a new state.

Similarly, the $U_s$ function takes as input the last state computed by the server and $n$ inputs coming from the $n$ clients for the corresponding tick. The $U_s$ function returns a new state, a server’s authoritative state.

We introduce a simple time function that associates a replica state $C_t^k$ or $S_t$ to a tick, corresponding to which tick this state is computed. For instance, $T(C_5^2)=5$ means that client 2 computed the state $C_5^2$ at tick $t=5$.

The clients update their state at each tick and compute the new state depending on the last received state from the server while applying the last inputs performed by the player. This leads to the following property:

This property characterizes the behavior of clients in rollback netcodes. In particular, rollback events are captured by the fact that if the server computes a game state that differs from the one locally computed by a client, specifically regarding the client’s own player, then the client’s subsequent computation of the game state will also differ from the case where both states initially matched. This divergence reflects the client’s need to re-simulate its local state based on the authoritative data received from the server.

The server updates its state as soon as it receives all the inputs necessary to compute it, depending on its last state. This led to the following property,

Note that, since the clients compute their state $C_t^k$ at tick $t$, they all send their input $I_t^k$ at tick $t$. Thus, the server can compute its $S_t$ state when the last input arrives, corresponding to the maximum latency of the clients at tick $t$.

Figure 3 illustrates these two properties.

It is important to emphasize that this model abstracts away several optimizations typically employed in real-world implementations of rollback netcode. In practice, clients do not always recompute the entire game state from the last authoritative server update: if the locally predicted state coincides with the server state, recomputation might be partially skipped, and the client simply continues its simulation without rollback. Similarly, various caching and incremental update mechanisms are used to reduce the computational cost of re-simulations. These implementation details, while crucial for efficiency and playability, are deliberately omitted here in order to focus on capturing the fundamental mechanisms and correctness properties of rollback netcodes.

Since we assume consistency, we have, for both $k_1$ and $k_2$:

In particular, using the definition of the $\oplus$ operator, we have, for all $t$:

Thus, by summing both terms, we have, for all $t$:

Since $\delta$ is a geometrical distance, by using the triangle inequality:

$◀$ Property 3 is a bound on semantic deviation between any client and the server. Naturally, Lemma 1 highlights a bound of semantic deviation between two clients.

Let’s show that theorem is an equivalence of Property 3. The sense of the Theorem to the property is direct (for $j=0$).

Let’s suppose that it exists $t$ and $j\in [O,{\max }_{k\in [1,n]}({\lambda }_t^k)+{\max }_k({\lambda }_{{\max }_k({\lambda }_t^k)}^k)]$, such that each client computes the state $t+j$, where, for a client $k_1$, the last received state from the server is $S_t$, while for a client $k_2$, the last received state from the server is $S_{t+1}$ (i.e., ${\lambda }_{t+1}^{k_1}>x>{\lambda }_{t+1}^{k_2}$). It is thus possible to find two inputs sequences ${(I_t^{k_1})}_t,{(I_t^{k_2})}_t$, such that each client respect the immersion-consistency proporty, but violate Lemma 1, where $\delta (C_{t+j}^{k_2},S_{t+1})\le \eta$, and $\delta (C_{t+j}^{k_1},S_t)\le \eta$, but $\delta (C_{t+j}^{k_1},C_{t+j}^{k_2})>2\eta$. Such a situation is illustrated in Figure 5. To avoid such a situation, it is thus necessary to limit every client semantically to the last received state by every client. Since the state $S_t$ is computed as time $T(S_t)=t+{\max }_k({\lambda }_t^k)$, all client must be bounded up to $t+{\max }_k({\lambda }_t^k)+{\max }_k({\lambda }_{{\max }_k({\lambda }_t^k)}^k)$.

$◀$

Theorem 2 is an equivalence of Property 3 (considering validity properties) and defines the requirements in terms of both latency and game semantics to ensure the immersion property. The main challenge highlighted here is that the evolution of a client’s state is highly dependent on the latency of other clients.

For instance, Theorem 2 emphasizes that if a client A experiences high latency, then client B must perform actions that are semantically close to its previous actions, with the degree of constraint depending on the severity of client A’s latency. In practice, enforcing such a requirement is highly challenging, as clients typically lack information about other clients’ latencies.

Moreover, this could open the door to potential attacks: a malicious client could deliberately increase its latency to disrupt other players’ gameplay, limiting their available actions.

A possible safeguard against this issue is to impose a maximum latency threshold, beyond which a timeout occurs. This approach is already used in some modern games [19, 1], where the server predicts a client’s input if the latency exceeds an acceptable limit. Such a safeguard is discussed in the Latency-based Attack subsection.

We recall that for all ticks $t$ and all clients $k$, we have ${\lambda }_t^k\ge 1$. Following Theorem 2, we thus have:

By summing the two terms, using the triangle inequality, we have:

Similarly, we have:

Thus, we have

concluding the proof. $◀$

Property 3 induces Corollary 3, but the contrary is false. However, it interestingly shows how clients and server must be bounded locally, in terms of semantics. Such a result is discussed in more detail when characterizing the special actions in the next subsection.