HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

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

New Issue
Open
opened 2026-07-15 10:04:35 +02:00 by Kyuubi · 0 comments
Kyuubi commented 2026-07-15 10:04:35 +02:00
Owner
Copy Link
Copy Source

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#24
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?