Proposal: SDR (Steam Datagram Relay) as optional transport backend for CGNAT traversal

[gabrielgad]

Problem

Players behind CGNAT (Carrier-Grade NAT) cannot port forward and have no direct path to host or join games without third-party tunneling (Ngrok, VPN, playit.gg). This affects:

• Apartment complexes with shared fiber routers — residents sit behind a NAT they don't control
• Mobile/5G ISPs — almost universally CGNAT'd
• Country-level CGNAT — Belgian carriers (Proximus, Telenet), and increasingly common worldwide as IPv4 exhaustion continues
• Corporate/university networks — firewalled with no port forwarding

STUN (hole-punching) does not solve this. Behind CGNAT with symmetric NAT, every outbound connection gets a different external port mapping, making the mapping STUN discovers useless for a different peer. The only solutions are relay-based: TURN, tunneling, or SDR.

Currently, users must set up Ngrok, a VPN (Hamachi, ZeroTier, Radmin), or playit.gg. This works but adds friction — people just want to play DSP with their friends, not debug networking infrastructure.

Proposal: Add SDR as an Optional Transport Backend

Add Steam Datagram Relay (SDR) support alongside the existing WebSocket transport using a backend selection system. This was discussed among contributors and the following principles were agreed on:

1. No platform exclusion — SDR must not remove functionality for Game Pass, WeGame, or any other platform
2. Backend selection — auto-detect platform and choose transport, with manual override
3. WebSocket remains the universal fallback — it works today, it stays
4. SDR is additive — a new option for Steam users, not a replacement

Terminology

• GNS (GameNetworkingSockets) — Valve's open-source, platform-agnostic transport layer (GitHub)
• SNS (SteamNetworkingSockets / ISteamNetworkingSockets) — the Steamworks proprietary build of GNS
• SDR (Steam Datagram Relay) — Valve's relay network, a feature on top of SNS. Only available to Steam users.

GNS is the transport. SDR is the relay. You can use GNS without SDR, and SDR requires Steam.

Architecture

+---------------------------------------+
|       Nebula Networking Layer         |
|  (packet processors, serialization,   |
|   game sync -- unchanged)             |
+---------------------------------------+
|       Transport Abstraction           |
|        (backend selector)             |
+------------------+--------------------+
|  WebSocket       |  SDR Tunnel        |
|  Backend         |  Backend           |
|                  |                    |
|  All platforms   |  Steam users       |
|  Direct/Ngrok/   |  P2P via Steam ID  |
|  VPN             |  Valve relay infra |
|  Port 8469       |  No port forward   |
+------------------+--------------------+

SDR Tunnel Approach

Rather than replacing WebSocket with SNS directly as a transport (which had fragmentation issues with large game state packets in past testing), SDR acts as a raw byte tunnel underneath WebSocket:

CLIENT                                       HOST

NebulaClient (WebSocket)                     NebulaServer (WebSocket)
  connects to localhost:9000                   listens on localhost:8469
        |                                              ^
        v                                              |
  [Local TCP Proxy]                            [Local TCP Proxy]
        |                                              ^
        v                                              |
  SteamNetworkingSockets P2P  ──── SDR ────  SteamNetworkingSockets P2P
  (small byte chunks only)                   (listen socket P2P)

WebSocket handles fragmentation and reliability as it does today. SDR only sees small TCP stream chunks (~1KB). The previous fragmentation problems with large factory/Dyson sphere/game state transfers are avoided because TCP segments them before they reach SDR.

Zero changes to packet processors, serialization, or game sync code. The tunnel is a self-contained component.

Connection Scenarios

Scenario	Transport	Relay	User Action
Steam ↔ Steam	WebSocket over SDR tunnel	Valve SDR	Join via Steam ID — no port forward needed
Steam ↔ Game Pass	WebSocket (direct)	Ngrok / VPN / playit.gg	Same as today — no regression
Game Pass ↔ Game Pass	WebSocket (direct)	Ngrok / VPN / playit.gg	Same as today — no regression

Backend Detection

TransportBackend ResolveBackend(TransportBackend userChoice)
{
    if (userChoice != TransportBackend.Auto)
        return userChoice;

    // Not on Steam (Game Pass, WeGame, etc.)
    if (!SteamAPI.IsSteamRunning() || !SteamManager.Initialized)
        return TransportBackend.WebSocket;

    // Steam China — SDR unavailable/unreliable
    if (SteamUtils.IsSteamChinaLauncher())
        return TransportBackend.WebSocket;

    // SDR relay reachable?
    var status = SteamNetworkingUtils.GetRelayNetworkStatus(out _);
    if (status != ESteamNetworkingAvailability.k_ESteamNetworkingAvailability_Current)
        return TransportBackend.WebSocket;

    return TransportBackend.SteamSDR;
}

User-facing settings:

• Auto (recommended) — detects platform, uses SDR if available
• Steam P2P — force SDR tunnel
• WebSocket — force WebSocket (for users who know they need it)

Prior Art & Context

Previous Transport Investigations

Transport	Result
LiteNetLib	Reliable but slow — no sliding window at the time, choked on large factory data. LNL has since received sliding window support: RevenantX/LiteNetLib#110
SteamNetworkingSockets (direct)	Fragmentation issues with large game state packets. GNS still lacks proper bandwidth estimation: ValveSoftware/GameNetworkingSockets#108
EOS	Excessive rate limiting
WebSocket (current)	Stable, reliable, but requires port forward/tunnel for WAN

Relevant earlier discussion: How do we handle transferring large amounts of data? — the core tension between TCP reliability for large transfers and UDP performance for gameplay has been a known issue since early development.

Why Not Just STUN/TURN?

• STUN doesn't work behind symmetric NAT / CGNAT — the user who brought this up is personally behind apartment complex CGNAT where STUN fails
• TURN requires hosting and maintaining a relay server, handling abuse prevention, paying for bandwidth
• SDR is essentially a free, Valve-maintained TURN equivalent for Steam users
• For non-Steam users, existing solutions (Ngrok, playit.gg, VPN) continue to work

SDR Authentication

From the Steamworks SDR docs: the game coordinator / auth server requirements apply to dedicated servers and non-Steam players. For Steam-to-Steam P2P:

"Steam does not restrict who can attempt to connect, aside from verifying that the player is signed into Steam and owns the game."

No auth server or game coordinator is needed for the P2P path between two Steam users.

Open Questions

1. Does SDR relay activate for DSP's AppID?

SDR relay may require the game's AppID (1366540) to be configured in the Steamworks partner backend. We don't have partner access. This needs to be validated with a PoC before committing to the full implementation.

Proposed PoC: Minimal BepInEx plugin that creates a SteamNetworkingSockets P2P connection between two machines behind NAT, tunnels a TCP echo server through it. If relay activates, the approach works.

2. InitRelayNetworkAccess() in BepInEx context

Needs testing to confirm it works from a mod where SteamAPI_Init() was already called by the game.

3. Future: GNS/LNL as direct transport replacement

Both GNS and LNL have evolved since they were last evaluated. A direct UDP transport (not tunneled) would improve performance but requires:

• Application-level chunking for bulk transfers (factory, Dyson sphere, game state) to avoid fragmentation
• Validation that sliding window / bandwidth estimation is sufficient

This is a separate investigation from the SDR tunnel work and can happen in parallel.

4. Non-Steam relay options

For Game Pass/WeGame users who need relay:

• Ngrok and playit.gg work today
• GSP-hosted relay is a possibility (needs further discussion)
• Community TURN server is an option but needs abuse mitigation and operational commitment

Proposed Implementation Phases

Phase 1: PoC — Validate SDR relay works for DSP's AppID with a minimal TCP ↔ SNS bridge between two CGNAT'd machines

Phase 2: Backend selection — Transport abstraction, platform detection, settings UI, status in /info

Phase 3: Integration — Wire SDR tunnel into host/join flow, Steam ID based joining, fallback handling, logging

Phase 4: Future transport investigation (separate track) — Re-evaluate LNL/GNS as direct transports, application-level chunking for bulk transfers, non-Steam relay options

References

• ISteamNetworkingSockets API
• Steam Datagram Relay docs
• GameNetworkingSockets (open source)
• GNS bandwidth estimation issue
• LNL sliding window issue
• Nebula: How do we handle transferring large amounts of data?

[Mushroom]

LGTM, I think that accurately surmises the conversation that was had on discord

[PhantomGamers]

1. Does SDR relay activate for DSP's AppID?
   SDR relay may require the game's AppID (1366540) to be configured in the Steamworks partner backend. We don't have partner access. This needs to be validated with a PoC before committing to the full implementation.

I am fairly certain on my Mirror Branch that I did test SDR and that it established fine without any changes needed on the partner dashboard, but definitely worth doing a PoC again anyway to confirm 100%.

I believe the only thing we'd need partner access for is doing stuff with Rich Presence as it requires the status strings be set on the Steam backend

Also I'd say there's a chance we can get the devs to make changes on the backend if we needed them to, not guaranteed but backend changes being needed doesn't necessarily mean it's a dead end either

[gabrielgad]

Want me to just build from the ground up? Back logged currently but I can get the skeleton and most of it up, idk if I'll be able to refine it and get it in its release state though.

[gabrielgad]

Want me to just build from the ground up? Back logged currently but I can get the skeleton and most of it up, idk if I'll be able to refine it and get it in its release state though.