Design an optional relay fallback from measured v1 traversal failures #24

New Issue

2026-07-15T10:04:35+02:00

Kyuubi commented

2026-07-15 10:04:35 +02:00

Parent: #1
Depends on: #23

Outcome

Decide whether a separate relay component is justified by production failure data, without silently expanding the v1 mediator into a gameplay proxy.

Scope

Analyze anonymized traversal outcome categories and affected consumer needs.
Compare dedicated-server fallback, third-party/platform relay, TURN-like UDP relay, and a purpose-built LiteNetLib relay.
Define trust, allocation, authentication, bandwidth quotas, abuse/DDoS controls, region selection, encryption, privacy, observability, cost, and capacity.
Keep relay data plane and lifecycle isolated from directory/mediator state and gameplay authority.
Specify SDK selection/fallback behavior and how games communicate relay limitations.
Produce an ADR and dependency-ordered implementation issues only if the evidence supports building it.

Acceptance criteria

The decision uses measured failure categories rather than assuming all NAT failures need an owned relay.
Operational and bandwidth cost estimates plus abuse risks are explicit.
No design makes Rendezvous authoritative for gameplay.
Direct connections remain preferred and relay credentials are short-lived/single-purpose.
“Do not build” or third-party relay is an acceptable documented outcome.
If approved, implementation, security, load, deployment, SDK, consumer, and GA issues are filed separately.

Parent: #1 Depends on: #23 ## Outcome Decide whether a separate relay component is justified by production failure data, without silently expanding the v1 mediator into a gameplay proxy. ## Scope - Analyze anonymized traversal outcome categories and affected consumer needs. - Compare dedicated-server fallback, third-party/platform relay, TURN-like UDP relay, and a purpose-built LiteNetLib relay. - Define trust, allocation, authentication, bandwidth quotas, abuse/DDoS controls, region selection, encryption, privacy, observability, cost, and capacity. - Keep relay data plane and lifecycle isolated from directory/mediator state and gameplay authority. - Specify SDK selection/fallback behavior and how games communicate relay limitations. - Produce an ADR and dependency-ordered implementation issues only if the evidence supports building it. ## Acceptance criteria - The decision uses measured failure categories rather than assuming all NAT failures need an owned relay. - Operational and bandwidth cost estimates plus abuse risks are explicit. - No design makes Rendezvous authoritative for gameplay. - Direct connections remain preferred and relay credentials are short-lived/single-purpose. - “Do not build” or third-party relay is an acceptable documented outcome. - If approved, implementation, security, load, deployment, SDK, consumer, and GA issues are filed separately.

Kyuubi referenced this issue

2026-07-15 10:04:52 +02:00

Roadmap: ship the Rendezvous connection control plane #1

Kyuubi referenced this issue

2026-07-16 22:40:30 +02:00

Run the real-network canary and declare Rendezvous v1 production-ready #23

Kyuubi referenced this issue

2026-07-17 00:25:10 +02:00

Roadmap: ship the Rendezvous connection control plane #1

Kyuubi referenced this issue

2026-07-17 02:24:18 +02:00

Run the real-network canary and declare Rendezvous v1 production-ready #23