Protocol Specifications

Technical deep-dive into the Rlay Tunneling Architecture (RTA) v2.0.
Optimized for High-Throughput Gaming & Low Latency.

01 Control & Data Handshake

Rlay uses a split-socket architecture. A primary Control Socket maintains the lifecycle of the session, while dynamic Data Sockets are spawned on-demand. This separation prevents head-of-line blocking.

// Actual Protocol Sequence
CLIENT -> AUTH:0:user_token_123
// Server validates & allocates port 10005
SERVER -> OK:10005
// When a player connects to public port:
SERVER -> CONN:sess_id_abc789
// Client opens new socket & pipes local data
CLIENT -> DATA:sess_id_abc789

02 Low-Latency Transport

TCP NoDelay (Nagle OFF)

Rlay explicitly disables Nagle's Algorithm (TCP_NODELAY) on all sockets. Game packets (Minecraft chunks, position updates) are flushed immediately to the network without buffering, reducing "rubber-banding" in multiplayer games.

Kernel-Level Piping

Data is piped directly between sockets in the relay node. We minimize user-space buffer copying, allowing the Linux Kernel to handle flow control. This ensures maximum throughput for large transfers.

03 Congestion Control (BBR)

Previous versions utilized software-based token buckets. Rlay v2.0 removes application-layer throttling entirely. We now rely on Google's BBR (Bottleneck Bandwidth and Round-trip propagation time) algorithm at the OS level.

Uncapped Bandwidth: Tunnels can burst to full link speed (1 Gbit/s+) depending on node load.
Bufferbloat Mitigation: BBR models the network path to avoid filling buffers, ensuring low ping even under heavy load.

04 Security Architecture

Process Isolation & Opacity

Rlay operates strictly as a Layer 4 (Transport) carrier. We do not inspect packet payloads. Your SSL/TLS termination happens on your local machine, meaning Rlay nodes cannot see your encrypted traffic. Idle connections are auto-pruned after 60 seconds to prevent resource exhaustion.