Multiplayer Relay Server Project

Project Overview

This project is a showcase of a Host Authoritative networking pipeline built for a real-time multiplayer implementation. It demonstrates a production-grade relay server capable of handling room management via TCP and high-frequency game state synchronization via UDP.

The core goal was to solve the "NAT Punch-through" problem without relying on expensive dedicated game servers for physics simulation, instead treating one client as the "Host" who owns the simulation authority.

---

🧠 Core Technical Learnings

1. Protocol Strategy: The Hybrid Approach

We adopted a hybrid networking model to balance reliability with speed:

• TCP (Port 9000): Used for Room Management (Lobby).
  • Why? Events like CreateRoom, JoinRoom, and PlayerJoined must be guaranteed. Dropping a "Player Joined" packet would break the game state logic. TCP ensures ordered, reliable delivery for these critical control messages.
• UDP (Port 9001): Used for In-Game Physics & Inputs.
  • Why? Fast-paced physics games generate state snapshots 60+ times a second. If a packet is lost, retransmitting it is useless because the data is already old. UDP provides the lowest latency "fire-and-forget" mechanism essential for smooth movement.

2. Architecture: Host Authoritative

We evaluated three common architectures before choosing Host Authoritative:

Architecture	Why we didn't use it	Why we chose Host Authoritative
Client Authoritative	High cheating risk. Clients just say "I am at X,Y". P2P mesh is complex to sync.	Security: In our model, regular clients only send inputs (WASD keys). The Host calculates the result. A hacked client can't just teleport.
Server Authoritative	requires running full physics engine (Unity/PhysX) on the backend. Expensive and complex to scale.	Cost & Simplicity: The server is just a "dumb relay". It doesn't need to know what a "Ragdoll" is. The Host (a player) runs the physics for free.

How it works in our MVP:

1. Regular Client: Sends inputs ({ "up": true }) to Server → Server forwards to Host.
2. Host Client: Receives inputs, simulates physics frame, and sends World State ({ "p1_pos": [10, 0] }) to Server.
3. Relay Server: Broadcasts World State to all Clients.

3. NAT Traversal & The Relay Pattern

One of the biggest hurdles in P2P gaming is NAT (Network Address Translation). Most home routers block incoming connections, making true Peer-to-Peer (Host <-> Client direct) impossible without complex techniques like UDP Hole Punching.

Our Solution: Custom TURN-like Relay Instead of fighting NAT, we built a lightweight efficient Relay Server acting as a middleman.

• Concept: Since the Server has a public IP, everyone can connect to it.
• The Relay acts purely as a pipe.
• Packet Flow: Client A (NAT) -> Relay (Public) -> Client B (NAT)
• This mimics the functionality of a TURN (Traversal Using Relays around NAT) server but optimized specifically for our game packets.

---

🛠 Project Structure

• relay_server/: The core Python backend.
  • Uses asyncio for high-concurrency non-blocking I/O.
  • Custom packet binary serialization using MessagePack (smaller & faster than JSON).
• test_client/: A Pygame-based client to validate the network layer.
  • Visualizes interpolation, packet loss, and jitter handling.

🚀 How to Run

Prerequisities

• Python 3.11+
• Poetry

1. Start the Relay Server

cd relay_server
poetry install
poetry run python -m src.relay_server.main

2. Start the Host Client

cd test_client
# This client will create a room and act as the physics authority
python run_client.py --host

3. Start a Joiner Client

cd test_client
# This client will join the room and send inputs
python run_client.py --join <ROOM_ID>