# 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.