# Session Logic and Timing Challenges

### Problem Statement

Session logic in multiplayer games often requires **timeouts and delays** for gameplay mechanics. For example, in a turn-based game, a round should resolve automatically after 30 seconds. In centralized applications, this is handled using threads that trigger timeouts. However, in a decentralized network, where session logic runs in parallel across multiple nodes, timing discrepancies arise due to:

* **Diverging states across nodes** when state-changing events arrive close to a timeout trigger.
* **Lack of a global synchronized clock**, making event ordering inconsistent.

A robust mechanism is needed to **ensure deterministic execution** of logic across all nodes while maintaining decentralization.

***

### Proposed Solution

In the decentralized network design, a **central coordinating actor**, called the **Coordinator**, organizes the network and acts as the primary point of interaction for clients.

***

### **Coordinator Responsibilities**

* Ensures timely responses to client requests.
* Triggers timeouts and propagates messages through a **ring topology**.
* Works with **Witness nodes**, which confirm events via double validation.

***

### **Ring-Based Request Propagation**

* Each request is sent through a **ring structure** to ensure redundancy and robustness.
* Witness nodes validate requests by ensuring they arrive from **both directions** before committing them.
* Similar to consensus protocols in distributed systems, this method ensures agreement across nodes.

***

### **Coordinator Selection and Timeouts**

* The **initial Coordinator** is randomly selected but will later be based on a **trust score** for reliability.
* The Coordinator is responsible for triggering all timeouts.
* Witness nodes **do not** trigger timeouts independently; they rely on timeout messages from the Coordinator.

***

### **Handling Conflicts and State Synchronization**

If a session logic timeout occurs, the network follows this process:

1. **Coordinator triggers a timeout** and propagates a message to all Witness nodes.
2. **Clients may send state-changing requests** that should cancel the timeout.
3. **Witness nodes apply a double confirmation** mechanism to ensure a valid timeout decision:
   * If a conflicting request is detected, the timeout is **canceled**.
   * Otherwise, the timeout is **executed**, and its result is added to the session proof.
4. **Coordinator drops any late-arriving conflicting requests** to prevent state inconsistency.

Witness nodes ensure that incorrect requests are filtered out:

* If a request arrives **after a timeout is triggered**, the Witness drops it.
* A redundant mechanism ensures incorrect requests **do not receive validation** from the ring topology.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://alliance-games.gitbook.io/alliance-games-gitbook/multiplayer-network/session-logic-and-timing-challenges.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.