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

Build a thin interactive Rendezvous test client #25

New Issue
Open
opened 2026-07-15 10:06:27 +02:00 by Kyuubi · 2 comments
Kyuubi commented 2026-07-15 10:06:27 +02:00
Owner
Copy Link
Copy Source

Parent: #1
Depends on: #9, #12, #13

Outcome

Provide a small standalone executable that exercises Rendezvous exactly as a game integration would, without requiring SpaceGame, Unscouted, Godot, or a custom test script.

Form

Create FinalFactory.Rendezvous.TestClient as a thin .NET console application. It must consume only the public Client and Contracts packages plus LiteNetLib; it must not reference Server internals or duplicate SDK behavior.

Scope

  • Support explicit host, browse, and join modes.
  • Host mode binds one LiteNetLib gameplay socket, publishes a session, refreshes lease/presence, accepts a connection ticket, and provides a minimal ping/echo exchange.
  • Browse mode lists compatible sessions using bounded filters and readable typed status output.
  • Join mode selects or accepts a session ID, requests a join, drives NAT introduction/direct connection on the same LiteNetLib socket, and exchanges ping/echo traffic.
  • Show phase transitions, elapsed times, selected endpoint type, and typed terminal outcomes without printing credentials, capabilities, tickets, or raw reusable secrets.
  • Provide both an interactive terminal flow and a non-interactive/scriptable mode with stable exit codes and optional JSON output for CI and operational smoke tests.
  • Accept service/game/environment/protocol/region and safe test metadata through command-line/configuration; never ship embedded production credentials.
  • Handle Ctrl+C, cancellation, timeout, reconnect attempts, service outage, and clean disposal.
  • Keep the client intentionally non-gameplay: no Godot UI, simulation, account system, matchmaking, or relay implementation.

Acceptance criteria

  • A clean invocation can host, browse, select, punch, authenticate, exchange direct ping/echo traffic, disconnect, and deregister.
  • Host and join modes use the same caller-owned LiteNetLib socket for mediation and direct traffic.
  • The executable proves direct peer traffic rather than routing echo through Rendezvous.
  • Interactive output distinguishes registration, browsing, authorization, presence, punch, direct-connect, host rejection, and fallback failures.
  • Script mode has documented stable exit codes and machine-readable output suitable for #14, deployment smoke checks, and runbooks.
  • Captured stdout/stderr and JSON contain no secrets, full tokens, or unsafe metadata rendering.
  • Timeout/cancellation/service failure exits within a bounded interval and leaves no background process or socket.
  • Tests use fakes for UI flow plus at least one real three-process integration path.
  • The README and integration guide identify this as diagnostic tooling, not a production game client or server-browser UI.
Parent: #1 Depends on: #9, #12, #13 ## Outcome Provide a small standalone executable that exercises Rendezvous exactly as a game integration would, without requiring SpaceGame, Unscouted, Godot, or a custom test script. ## Form Create `FinalFactory.Rendezvous.TestClient` as a thin .NET console application. It must consume only the public `Client` and `Contracts` packages plus LiteNetLib; it must not reference Server internals or duplicate SDK behavior. ## Scope - Support explicit `host`, `browse`, and `join` modes. - Host mode binds one LiteNetLib gameplay socket, publishes a session, refreshes lease/presence, accepts a connection ticket, and provides a minimal ping/echo exchange. - Browse mode lists compatible sessions using bounded filters and readable typed status output. - Join mode selects or accepts a session ID, requests a join, drives NAT introduction/direct connection on the same LiteNetLib socket, and exchanges ping/echo traffic. - Show phase transitions, elapsed times, selected endpoint type, and typed terminal outcomes without printing credentials, capabilities, tickets, or raw reusable secrets. - Provide both an interactive terminal flow and a non-interactive/scriptable mode with stable exit codes and optional JSON output for CI and operational smoke tests. - Accept service/game/environment/protocol/region and safe test metadata through command-line/configuration; never ship embedded production credentials. - Handle Ctrl+C, cancellation, timeout, reconnect attempts, service outage, and clean disposal. - Keep the client intentionally non-gameplay: no Godot UI, simulation, account system, matchmaking, or relay implementation. ## Acceptance criteria - A clean invocation can host, browse, select, punch, authenticate, exchange direct ping/echo traffic, disconnect, and deregister. - Host and join modes use the same caller-owned LiteNetLib socket for mediation and direct traffic. - The executable proves direct peer traffic rather than routing echo through Rendezvous. - Interactive output distinguishes registration, browsing, authorization, presence, punch, direct-connect, host rejection, and fallback failures. - Script mode has documented stable exit codes and machine-readable output suitable for #14, deployment smoke checks, and runbooks. - Captured stdout/stderr and JSON contain no secrets, full tokens, or unsafe metadata rendering. - Timeout/cancellation/service failure exits within a bounded interval and leaves no background process or socket. - Tests use fakes for UI flow plus at least one real three-process integration path. - The README and integration guide identify this as diagnostic tooling, not a production game client or server-browser UI.
Kyuubi self-assigned this 2026-07-16 10:19:36 +02:00
Kyuubi commented 2026-07-16 10:19:42 +02:00
Author
Owner
Copy Link
Copy Source

Starting implementation on stacked branch codex/issue-25-test-client, based on verified issue #13 commit 94aba8a. I’ll first inventory the existing TestClient scaffold and public SDK surface, then implement the public-package-only host/browse/join flows, stable script/JSON contract, bounded shutdown/error handling, tests, documentation, and a real process-level smoke path. Issue #14 will follow once this prerequisite is complete.

Starting implementation on stacked branch `codex/issue-25-test-client`, based on verified issue #13 commit `94aba8a`. I’ll first inventory the existing TestClient scaffold and public SDK surface, then implement the public-package-only host/browse/join flows, stable script/JSON contract, bounded shutdown/error handling, tests, documentation, and a real process-level smoke path. Issue #14 will follow once this prerequisite is complete.
Kyuubi commented 2026-07-16 11:06:28 +02:00
Author
Owner
Copy Link
Copy Source

Implemented and pushed on codex/issue-25-test-client at 7e3be2c.

Delivered:

  • standalone host/browse/join TestClient using only public Client/Contracts APIs plus LiteNetLib
  • caller-owned UDP socket with authenticated direct ping/echo/ack/completion proof
  • stable human and JSON v1 events/exit codes, bounded lifecycle, dedicated-fallback reporting, and secret-safe output
  • fake command tests plus a real server/host/browse/join multi-process test with dynamic ports, cleanup enforcement, and post-deregistration verification
  • integration and tool documentation

Adversarial review: all reported P0/P1/P2 findings resolved.

Verification:

  • Debug build: pass
  • Debug tests: 213/213
  • Release build: pass
  • Release tests: 213/213
  • formatting and diff hygiene: pass
  • Release publish and published-artifact JSON help/invalid-config smoke tests: pass

The issue remains open while the dependency stack is completed and landed.

Implemented and pushed on `codex/issue-25-test-client` at `7e3be2c`. Delivered: - standalone host/browse/join TestClient using only public Client/Contracts APIs plus LiteNetLib - caller-owned UDP socket with authenticated direct ping/echo/ack/completion proof - stable human and JSON v1 events/exit codes, bounded lifecycle, dedicated-fallback reporting, and secret-safe output - fake command tests plus a real server/host/browse/join multi-process test with dynamic ports, cleanup enforcement, and post-deregistration verification - integration and tool documentation Adversarial review: all reported P0/P1/P2 findings resolved. Verification: - Debug build: pass - Debug tests: 213/213 - Release build: pass - Release tests: 213/213 - formatting and diff hygiene: pass - Release publish and published-artifact JSON help/invalid-config smoke tests: pass The issue remains open while the dependency stack is completed and landed.
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 Kyuubi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#25
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?