commit 7ebcb0f0abbf77128de5d3bd63cf15c0a7174ca9 Author: Cyd Date: Fri Jul 10 10:31:34 2026 -0500 Initial brainstorm record: linking Pod Bays across the internet - README: project charter + seed concept (per-site 10.0.y.0/24 subnets, VPN into one /16, merged siteconfigs -> master console) - docs/PODBAY-ECOSYSTEM: survey of the existing bay stack with source pointers (TeslaSuite RPC 53290, Firestorm DirectPlay 4 + CTCL, BT411 console/egg protocol, RP Munga 1501, PQS, port map) - docs/BRAINSTORM: addressing plan, routed-L3 vs bridged-L2 analysis, master console vs federation, per-game linking, shared services, security posture, open questions, phased roadmap - sites/: site-ID / subnet registry (public info only) Co-Authored-By: Claude Fable 5 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..25384d0 --- /dev/null +++ b/.gitignore @@ -0,0 +1,9 @@ +# Secrets never enter this repo +*.siteconfig +*wg-private* +*.key +*.pem + +# Local scratch +scratch/ +*.log diff --git a/README.md b/README.md new file mode 100644 index 0000000..9baff49 --- /dev/null +++ b/README.md @@ -0,0 +1,39 @@ +# SiteLink + +**Linking multiple VWE Pod Bays together to play games across the internet.** + +A Pod Bay today is an air-gapped network of ~20 computers: 1 command console, 1 printer, +2 review stations (Live Cam & Mission Review), and 16 cockpit computers. SiteLink is the +project to connect those islands — so a bay in one city can field a lance against a bay in +another, share a queue, share voice, and (eventually) be commanded as one fleet. + +## Seed concept (2026-07-10) + +> Organize each site into its own `10.0.y.x` subnet (site 1 = `10.0.1.x`, site 2 = +> `10.0.2.x`, …), VPN them all together into a single `10.0.0.0/16`, then collect every +> site's `.siteconfig` and merge them for a **master console** that can command the +> entire fleet. + +That concept is the anchor of this repo. The analysis, alternatives, and open questions +live in the docs below. + +## Contents + +| File | What it is | +|------|-----------| +| [docs/PODBAY-ECOSYSTEM.md](docs/PODBAY-ECOSYSTEM.md) | Survey of the existing bay software stack — every component, every protocol/port, with source pointers into the sibling repos. The ground truth SiteLink has to work with. | +| [docs/BRAINSTORM.md](docs/BRAINSTORM.md) | The design record: goals, the seed proposal analyzed, addressing plan, VPN topology options (routed vs bridged), master-console vs federation, per-game linking analysis, shared services, security, open questions, and a phased roadmap. | + +## Related repositories (gitea.mysticmachines.com/VWE) + +| Repo | Role | +|------|------| +| `TeslaSuite` | TeslaConsole (operator console), TeslaLauncher (pod service), the Console↔Pod RPC contract, SecureConfig provisioning, and **vPOD** (virtual pod — our cross-site test double). | +| `firestorm` | BattleTech: Firestorm — the MW4/Gameleap-engine game the 16 cockpits run. DirectPlay 4 multiplayer. Contains the drafted 16→32 player-cap plan that a two-bay link needs. | +| `RP411` | Red Planet (MUNGA engine, Win32/DX9 port). Console-controlled via Munga protocol, TCP 1501. | +| `BT411` | Classic arcade BattleTech (Tesla 4.10) reconstruction on the RP411 engine. Console streams the mission egg over TCP; pods mesh with each other. | +| (local `PQS/`) | Pod Queue System — PHP/MySQL front-of-house: registration, callsigns, queue, and the HTTP endpoints the game/console poll for the next mission + roster. | + +## Status + +Brainstorm / design phase. Nothing here touches a live bay yet. diff --git a/docs/BRAINSTORM.md b/docs/BRAINSTORM.md new file mode 100644 index 0000000..314f622 --- /dev/null +++ b/docs/BRAINSTORM.md @@ -0,0 +1,231 @@ +# SiteLink — design brainstorm + +Working record, started 2026-07-10. Companion to +[PODBAY-ECOSYSTEM.md](PODBAY-ECOSYSTEM.md), which holds the verified facts this +brainstorm builds on. + +## 0. Goals (proposed — confirm/edit) + +1. **Cross-site play**: cockpits at site A and site B in the same match (Firestorm first; + BT411/RP as they mature). +2. **Preserve the air gap**: the linked fleet is one private network. No bay machine ever + gets a route to the general internet. +3. **Fleet visibility/command**: an operator (eventually a master console) can see — and + where appropriate command — pods at every site. +4. **Shared front-of-house**: cross-site events share a queue, callsigns, scores, voice. +5. **Zero changes to cockpit hardware**, minimal changes to bay-local operation: a bay + must keep working stand-alone when the link is down. + +Non-goals (for now): public matchmaking, spectating from home, per-player home clients. + +## 1. The seed proposal + +> Each site gets its own `10.0.y.x` subnet (we get `10.0.1.x`, you get `10.0.2.x`, …), +> VPN them all together into a single /16, collect every site's `.siteconfig`, +> concatenate them, and give the result to a master console that commands the fleet. + +**Verdict: sound skeleton.** The three pieces (site-numbered subnets, VPN mesh into +`10.0.0.0/16`, merged fleet config) survive contact with the code. The refinements below +are about *how*, not *whether*. + +## 2. Addressing plan + +- **`10.0..0/24` per site**, keeping each bay's existing last-octet conventions + (pods `.1–.8`, `.11–.18`, camera `.9`, …) so per-site configs become a template + stamped with a site ID. Legacy `200.0.0.x` bays get renumbered on joining — that + space is public internet space and must not exist inside the linked fleet. +- **Reserve `10.0.0.0/24` for shared infrastructure**: VPN hub, master console, central + PQS, Mumble, NTP, a neutral dedicated game host. Nothing site-specific lives there. +- **Site ID registry lives in this repo** (`sites/` — one small file per site: ID, name, + operator, subnet, contact). First allocation: `10.0.1.0/24` = Fallout Shelter Arcade; + `10.0.2.0/24` = next site. 254 sites max — plenty. +- **Netmask choice is the real design fork** (see §3): hosts configured `/24` + gateway + = routed model; hosts configured `/16` = requires a bridged L2 overlay. +- Renumbering mechanics: TeslaConsole already owns pod IP config (provisioning writes + `mIPAddress/mGateway/mDns/mSubnet`), and the CTCL `[teslas]` inis are trivially + regenerated from a template. So renumbering is a console-driven afternoon, not a + reimage. + +## 3. Topology: routed L3 vs bridged L2 + +### Option A — Routed L3 (recommended default) +Each site keeps its `/24`; a per-site VPN gateway (its *only* new hardware) routes +between sites over **WireGuard** tunnels. + +- ✅ Works because Firestorm's join path is **directed by IP** (`TryToJoinASpecificGame`, + see ecosystem doc) and every console→pod protocol (53290 RPC, Munga 1501, BT egg + push) is directed TCP. Nothing in the *match-play* path needs broadcast. +- ✅ Clean failure isolation, no cross-WAN broadcast chatter from era Windows boxes, + easy per-flow firewalling at each gateway. +- ✅ Hub-and-spoke (hub on shared infra, e.g. alongside mysticmachines.com) or full mesh — + WireGuard does either; start hub-and-spoke, it's simpler and the hub is also where + shared services live. +- ⚠️ Breaks broadcast-dependent conveniences: DirectPlay "browse LAN games" listing and + SecureConfig first-boot beacons don't cross sites. Both are acceptable: game joins are + console-directed anyway, and provisioning is an on-site act by design. + +### Option B — Bridged L2 overlay (fallback / experiment) +One virtual Ethernet across all sites (ZeroTier, VXLAN/EoIP between gateways, tinc +switch mode); hosts could then even use a flat `/16`. + +- ✅ Everything behaves like one big LAN — broadcast discovery, any undiscovered + broadcast assumption in 1996–2009 era code, zero renumbering logic beyond uniqueness. +- ❌ One broadcast domain of ancient unpatched Windows across the WAN (NetBIOS chatter, + broadcast storms), MTU headaches, harder to reason about, and failure at one site can + be noisy everywhere. +- Position: **keep in the back pocket.** If Phase-0 testing (vPOD + two subnets) turns up + a flow that genuinely requires broadcast, bridge *only* that (e.g. a targeted UDP + broadcast relay) before going full L2. + +### VPN tech choice +WireGuard first (kernel-fast, tiny config, UDP hole-punch friendly, runs on a $50 box or +the site router). Tailscale/NetBird/ZeroTier are managed alternates if key/peer +management becomes a burden — but note ZeroTier is the L2 option, Tailscale/NetBird are +L3. The bay machines themselves never run VPN software; only the per-site gateway does. +**Bay boxes keep no default route** — gateways carry routes for `10.0.0.0/16` only. + +## 4. Fleet configuration: master console vs federation + +The seed proposal: merge all `.siteconfig` files → one master console commands the fleet. + +**Reality check on "concatenate":** `local.siteconfig` is a BinaryFormatter object graph +(Squad → Pods), not a text file — merging means a small tool that deserializes N +siteconfigs and emits one multi-squad config. Straightforward since TeslaConsole is +rebuilt from source; the natural mapping is **one Squad per site** ("FSA-bay1", +"Pharaoh-bay1", …). TeslaConsole's UI already organizes pods by squad. + +**Security consequence:** a pod's `mKey` in the siteconfig *is* command authority over +that pod. Shipping your siteconfig to a master console = granting fleet-wide control. +Fine between trusted operators, but do it deliberately: + +- Siteconfigs travel operator-to-operator over a secure channel; **never through this + repo** (repo carries the merge tool + templates only). +- A master console with all keys is a single high-value target — it lives on shared + infra (`10.0.0.0/24`), not on someone's laptop. + +**Three architectures, in order of effort:** + +1. **Merged-config master console (the seed).** One TeslaConsole instance with all + squads/keys. Cheapest to reach; needs the merge tool + WAN-tolerant RPC timeouts. + Risks: WAN blip mid-install, and two consoles (site + master) commanding the same pod + concurrently — the launcher has no arbitration. Convention needed: master commands + only during cross-site events, site console otherwise. +2. **Hybrid (probably the sweet spot).** Site consoles stay authoritative for + provisioning/installs; the master console gets *visibility everywhere* + + *game-orchestration rights* during events. Could be as simple as (1) plus agreed + scope, or a read-only fleet mode in TeslaConsole. +3. **Federation service.** A SiteLink coordinator each site console registers with; the + coordinator brokers cross-site game setup, no raw pod keys leave a site. Cleanest + trust story, most new code. Later phase, if the fleet grows past a handful of + trusted operators. + +## 5. Linking the games themselves + +### Firestorm (first target) +- **Session model:** one DirectPlay host; everyone joins directed-by-IP. Options for + host placement: + - a) Host at one site's console (simplest; other site eats the WAN RTT; O(n²) load on + that console's uplink); + - b) **Neutral dedicated host** on shared infra (`mw4dedicatedui` exists!) — + symmetric latency for both sites, best uplink, and the camera/review stations at + *each* site can join as local spectators. Needs validation that the dedicated + server builds/runs (it's in the solution but unexercised in the modern work). +- **Player counts:** the golden first milestone is **8v8 across two sites (8 cockpits + each) — inside the stock 16-player cap, zero engine changes.** Full 16v16 site-vs-site + needs the already-drafted 16→32 plan in `firestorm\CLAUDE.md` (compiled defaults + + drop-zone authoring per map + lobby UI polish). +- **Latency budget:** the netcode shipped for dial-up (150–300 ms era). Inter-city + internet (20–80 ms) + WireGuard (~1 ms) should be comfortable. Measure, don't assume: + put netem delay/jitter/loss on a test gateway and find the cliff (see Phase 0). +- **Port hygiene:** set the `DirectPlayPort` registry value at every site so game traffic + is a single known port for the gateways' firewalls, instead of DirectPlay's default + 47624 + 2300–2400 spread. +- **Fixed-port + MTU checks:** DirectPlay UDP datagrams over a 1420-byte WireGuard MTU — + verify no fragmentation weirdness (era stacks are fragile here). + +### BT411 (classic BattleTech) +- The console already launches multi-pod games by address list (`btconsole.py MP.EGG + 10.0.1.11:1501 10.0.2.11:1501` *is* a cross-site launch). Two unknowns to resolve: + 1. Does the pod↔pod mesh derived from the egg `[pilots]` list carry literal IPs + (routes fine) or assume same-subnet? + 2. The 1996 sim's latency tolerance — lockstep-ish engines of that era can be + unforgiving. netem test early. +- Console-must-stay-connected quirk means the WAN link drop kills the match — argues for + running the BT console *at the site with the most pods*, or fixing the engine bug. + +### Red Planet +- Same console-directed model (Munga TCP 1501). Park until BT411 learnings land — shared + engine lineage means most answers transfer. + +## 6. Shared services (the `10.0.0.0/24` rack) + +| Service | Notes | +|---------|-------| +| WireGuard hub | The rendezvous point; a VPS (could sit near the existing mysticmachines.com infra) or a box at the best-connected site | +| Mumble | Cross-site voice day one — the FS507D release already integrated Mumble on the bay side. Channel per team, cross-team lobby channel | +| Central PQS (event mode) | Cross-site events need one queue/roster. Options: (a) one central PQS all consoles poll — simplest, DB schema grows a `site` column; (b) per-site PQS + sync — only if WAN-down resilience of the local queue matters during events. Callsign uniqueness becomes fleet-wide (global registration table) | +| Neutral game host | Firestorm dedicated server for site-vs-site matches | +| NTP | One clock for scores, logs, and replay/debrief alignment | +| Fleet monitoring | VncThumbnailViewer pointed across the VPN; later, master-console status board | + +Local-only forever: printer, RIO/cockpit I/O, Mission Review & Live Cam *stations* +(they join the match as spectators over the VPN, but the screens/printer serve the local +audience). Cross-site match results reach both printers via PQS/debrief distribution — +worth a small design of its own later. + +## 7. Security posture + +- **The fleet stays air-gapped as a whole.** Only gateways touch the internet, only to + carry WireGuard to known peers. Bay machines: no default route, no DNS egress, static + `10.0.0.0/16` routes via the gateway. +- **Gateway firewall = allowlist by flow**, per the port map in the ecosystem doc. + Suggested split: + - *Game plane* (DirectPlay fixed port, Munga 1501, Mumble): site↔site and site↔shared. + - *Management plane* (TCP 53290 launcher RPC, VNC 5900): only site-console↔own-pods + and master-console↔pods — other sites' consoles have no business on your 53290. +- **Secrets:** siteconfigs (pod keys) and WireGuard private keys never enter this repo. + Repo holds templates, tools, and *public* site registry data (subnets, endpoints' + hostnames, WireGuard public keys). +- Era-Windows reality: assume every bay box is compromised-if-reachable. The allowlist + above is the actual security boundary; the VPN is transport, not trust. + +## 8. Open questions + +1. **FS end-to-end join over routed subnets** — directed-join API confirmed in source; + prove the whole ConLobby/CTCL flow passes the host IP (vPOD + two subnets, or two + VMs). Any broadcast dependency hiding in the lobby flow? +2. **`DirectPlayPort` in practice** — is it set at existing sites, and does a fixed port + carry all session traffic (or only enumeration) under DirectPlay Protocol? +3. **BT411 `[pilots]` mesh** — IPs or subnet assumptions? (Read `L4NET.CPP` + StartConnecting path.) +4. **Latency cliffs per title** — netem sweep: at what RTT/jitter/loss does each engine + degrade (rubber-banding, desync, disconnect)? +5. **Dedicated Firestorm host** — does `mw4dedicatedui` build & run in the modern tree, + and can camera/MR spectators join it cleanly? +6. **PQS multi-site schema** — site column vs event database; global callsign policy. +7. **Master-console arbitration** — what happens when site + master consoles command the + same pod; do we need a soft lock ("bay is in fleet mode")? +8. **Who hosts shared infra** — VPS vs best-connected site; bandwidth math for a + 32-player O(n²) host (~upstream estimate needed from real packet captures). +9. **Site count ambitions** — 2 sites soon, how many eventually? Affects hub sizing and + whether federation (§4.3) is ever needed. +10. **WAN-drop behavior** — for each linked flow, what breaks when the tunnel drops + mid-match, and does the bay cleanly fall back to stand-alone? + +## 9. Phased roadmap (strawman) + +- **Phase 0 — Lab proof (no hardware, no travel).** Two "bays" as VMs/vPOD instances on + two subnets with a WireGuard/netem gateway between them. Prove: console→remote-pod + RPC (53290), a 2-client Firestorm match across subnets, latency sweep, BT411 + cross-subnet egg push. *Everything above that's marked "verify" gets verified here.* +- **Phase 1 — First real link.** Two sites, gateways, tunnel, renumber to + `10.0.1.x`/`10.0.2.x`. Mumble + fleet VNC + remote Mission-Review spectating. First + cross-site Firestorm match at ≤16 total players (8v8) on the stock exe. +- **Phase 2 — Fleet operations.** siteconfig merge tool → master console visibility + (hybrid model, §4.2). PQS event mode with shared queue/callsigns. Debrief/scoresheet + distribution to both printers. +- **Phase 3 — Full site-vs-site.** Execute the firestorm 16→32 plan (code defaults + + drop zones), neutral dedicated host, 16v16 events. +- **Phase 4 — More titles, more sites.** BT411/RP cross-site as those engines mature; + 3rd+ site onboarding kit (gateway image + site-ID allocation + config templates); + revisit federation and the GUN/GameSpy-style fleet game browser. diff --git a/docs/PODBAY-ECOSYSTEM.md b/docs/PODBAY-ECOSYSTEM.md new file mode 100644 index 0000000..5b4b3c0 --- /dev/null +++ b/docs/PODBAY-ECOSYSTEM.md @@ -0,0 +1,129 @@ +# The Pod Bay ecosystem — what SiteLink has to work with + +Surveyed 2026-07-10 from the sibling repos under `C:\VWE`. Every claim below has a source +pointer so it can be re-verified as those repos evolve. + +## 1. Physical bay composition + +A Pod Bay is **an air-gapped network of ~20 computers**: + +| Count | Machine | Software role | +|------:|---------|---------------| +| 1 | Command console | Operator station: TeslaConsole (pod management) + the game's console/lobby (Firestorm "BattleTech Console" ConLobby, or the era console for BT/RP) + PQS front-of-house | +| 16 | Cockpit computers | Run the game exe in pod mode (`-ctcltype 2` for Firestorm) with cockpit I/O (RIO boards → RioJoy/VRio joystick layer) | +| 1 | Live Cam station | Firestorm: game exe as camera ship (`-ctcltype 3`, `ctcl-camera.ini`) | +| 1 | Mission Review station | Firestorm: `ctcl-mr.ini`; engine has a dedicated `MSRSpectator` project (`firestorm\Gameleap\code\mw4\Code\MSRSpectator`) | +| 1 | Printer | Debriefing / scoresheet output (`printdebriefing` flag in PQS game config) | + +Air-gapped is a *feature*: the cockpit boxes run era Windows images, deliberately hardened +and never internet-exposed (TeslaLauncher's `install.bat` hardens the box). SiteLink must +preserve that property — the linked fleet becomes one bigger air-gapped network, not 20×N +machines on the internet. + +## 2. Addressing conventions found in the wild + +- **Dev/legacy bays:** `200.0.0.x` — pods at `.1–.8` and `.11–.18`, camera ship at `.9` + (see `firestorm\MW4\ctcl-game.ini` `[teslas]`). Note `200.0.0.0/8` is *public* address + space — harmless while air-gapped, a real conflict once bays are routed together. +- **FS507D 2016 LAN-center release:** per-machine `10.0.0.x` (release `postinstall.bat`, + ctcl inis) — already in RFC1918 space, and the convention the SiteLink seed proposal + generalizes to `10.0..x`. + +## 3. Components and their wire protocols + +### TeslaConsole ↔ TeslaLauncher (pod management plane) +- **TCP 53290**, length-prefixed JSON frames over an OFB-encrypted stream; per-pod key + (`TeslaSuite\Contract\PodRpcProtocol.cs`). Console provisions, installs products on, + and launches games on pods. +- **First-boot provisioning:** UDP beacons + RSA key exchange (`TeslaSuite\SecureConfig\`) + — *broadcast-based, local-subnet only*. Provisioning is inherently an on-site act. +- **`local.siteconfig`** (`C:\VWE\local.siteconfig`): .NET BinaryFormatter graph of + `TeslaConsole.Squad` (mGuid, mName, mOnline) → `TeslaConsole.Pod` records: + `mId, mIPAddress, mGateway, mDns, mSubnet, mHostName, mKey, mMacAddress, mName, + mPodArtPath, mHostType, mOnline`. Two consequences for SiteLink: + 1. "Concatenating" siteconfigs = a real deserialize/merge/reserialize tool (or native + multi-site support in TeslaConsole — buildable, since the console is now rebuilt + from source). The `Squad` concept maps naturally to "one squad per site". + 2. `mKey` is the credential that lets a console command a pod. **Siteconfig files are + secrets.** Sharing one with a master console = handing over control of your bay. +- **vPOD** (`TeslaSuite\vPOD\`): impersonates both a pod's launcher (TCP 53290) and a + game client (Munga TCP 1501). **This is our test double for a whole remote bay** — we + can prototype every SiteLink flow without touching cockpit hardware. + +### Firestorm (MW4/Gameleap engine) — the flagship game +- **Game transport: DirectPlay 4** (`IDirectPlay4A`, TCP/IP service provider, DirectPlay + reliable protocol enabled) — `firestorm\...\GameOS\Net_Main.cpp:387,2226`. + - Port: registry value `DirectPlayPort` (`Games_LAN.cpp:2307`); `0` = stock DirectPlay + ports (TCP/UDP 47624 enumeration + dynamic 2300–2400 range). Setting it fixed makes + firewalling exact. + - **Directed join works without broadcast:** `TryToJoinASpecificGame(szIPAddress, name)` + builds a compound address with `DPAID_INet = host IP` and unicasts the session + enumeration (`Net_Main.cpp:2887–2937`). Broadcast is only the "browse LAN games" + path. **This is what makes routed (L3) site-linking viable.** + - Player cap: compiled default **16** (`MW4Shell.cpp:13319`); engine arrays go to 255. + A drafted, phased **16→32 plan** exists in `firestorm\CLAUDE.md` (code defaults + + lobby UI + ≥32 drop zones per map). Two full bays in one match needs it; one bay's + 16 split across two sites does not. + - Replication is ~O(n²) at the session host — host placement/upstream matters. +- **CTCL (cafe/Tesla control layer):** `ctcl.dll`/`ctcls.dll` + per-role inis + (`ctcl-game.ini`, `ctcl-camera.ini`, `ctcl-mr.ini`): `[teslas]` maps pod IP → pilot + seat; `[Games]` lines carry the exe + `-ctcltype` role; aux-message and taunt tables. + The bay roster is **static config**, which is exactly what a site-ID-based addressing + scheme can template. +- **Dedicated server exists:** `mw4dedicatedui` project (`...\mw4\Code\mw4dedicatedui`) — + option to host cross-site matches on a neutral box instead of one bay's console. +- **Dormant internet-era code:** MSN Zone "GUN" matchmaking (`Games_GUN.cpp`, + `GUNGameList.h`) and GameSpy advertisement (`Games_GSpy.cpp`) — dead services, live + code paths; a revival hook if SiteLink ever wants a fleet-wide game browser. +- **2016 release integrated Mumble** for voice (FS507D postinstall) — cross-site voice is + a solved problem: one Mumble server on the shared network. + +### BT411 (classic BattleTech, Tesla 4.10 reconstruction) +- **Console-push model over plain TCP:** the console connects to each pod's `-net ` + listener (convention 1501/1601), streams the mission egg in 1040-byte framed chunks, + then sends `RunMission` twice (`BT411\tools\btconsole.py` documents the full wire + format, verified against the engine). +- Pods form their mesh from the egg's `[pilots]` list; the console must stay connected + for the duration (engine quirk: console loss also closes the game listener). +- Cross-site implication: `btconsole.py MP.EGG 10.0.1.11:1501 10.0.2.11:1501` is *already* + a cross-site game launch, modulo whatever the pod↔pod mesh needs (open question: does + the `[pilots]` list carry literal IPs? → see BRAINSTORM open questions). +- Status: entity/movement replication works; cross-pod combat in progress. + +### Red Planet (RP411 / RP 4.11.4) +- MUNGA engine, console game-control via **Munga protocol, TCP 1501** (vendored + `Munga Net.dll` in TeslaConsole). Same console-directed model as BT411 (shared engine + lineage — `MUNGA_L4\L4NET.CPP`). + +### PQS — Pod Queue System (front of house) +- XAMPP (Apache/PHP/MySQL) app: registration, callsigns, combined queue displays, + history/search (`PQS\*.php`). +- The game/console side **polls simple HTTP endpoints**: `getFSgame.php` prints the next + mission's game type/map/16 condition flags; `getFSplayers.php` the roster. MySQL db + `pqs`, tables `pqs_gameconfig`, `pqs_queue`, `pqs_mission`. +- Single-site by construction today (localhost MySQL, one queue). Multi-site play needs + either a shared central PQS or per-site PQS with an event/sync mode. + +### Support tooling +- **VncThumbnailViewer** (`C:\VWE\VncThumbnailViewer`): operator monitoring of pod + screens — works fine across a VPN, and a master console could reuse it for fleet-wide + eyes-on. +- **RioJoy / VRio**: cockpit hardware I/O → joystick. Purely local to each cockpit; + SiteLink never touches it. +- **SheepShaver**: classic-Mac emulation (the original 1990s VGL-era console stack) — + heritage/reference only. +- **blackthorn**: archived site builds (Airlock standard install 2018, Firestorm SMT + builds) — useful as references for how deployed sites were actually configured. + +## 4. Port map (current, single bay) + +| Port | Proto | Flow | Purpose | +|------|-------|------|---------| +| 53290 | TCP | console → pod | TeslaLauncher RPC (provision/install/launch), OFB-encrypted framed JSON | +| (local bcast) | UDP | pod ↔ console | SecureConfig first-boot beacons (on-site only) | +| 1501 | TCP | console → pod | Munga game control (RP; BT411 uses same convention, port per `-net`) | +| 47624 + 2300–2400, or fixed `DirectPlayPort` | TCP/UDP | pod ↔ session host | Firestorm DirectPlay 4 session + game traffic | +| 80 | TCP | console/game → PQS box | PQS HTTP endpoints | +| 3306 | TCP | PQS internal | MySQL (localhost today) | +| 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention) | +| 5900 | TCP | operator → pods | VNC monitoring (optional) | diff --git a/sites/README.md b/sites/README.md new file mode 100644 index 0000000..1a1bcdd --- /dev/null +++ b/sites/README.md @@ -0,0 +1,13 @@ +# Site registry + +One file per site: `NN-shortname.md` where `NN` is the site ID (third octet of the +site's `10.0.NN.0/24` subnet). IDs are allocated here, first-come, by PR/commit. + +**Public info only** — subnet, operator, contact, WireGuard *public* key and endpoint +hostname. Siteconfigs (pod keys) and WireGuard private keys never go in this repo. + +| ID | Subnet | Site | Status | +|----|--------|------|--------| +| 0 | 10.0.0.0/24 | (reserved) shared infrastructure — hub, master console, PQS, Mumble, NTP, dedicated host | reserved | +| 1 | 10.0.1.0/24 | Fallout Shelter Arcade | allocated | +| 2 | 10.0.2.0/24 | (next site) | open |