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 <noreply@anthropic.com>
This commit is contained in:
Claude Fable 5
@@ -0,0 +1,9 @@
|
||||
# Secrets never enter this repo
|
||||
*.siteconfig
|
||||
*wg-private*
|
||||
*.key
|
||||
*.pem
|
||||
|
||||
# Local scratch
|
||||
scratch/
|
||||
*.log
|
||||
@@ -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.
|
||||
@@ -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.<siteID>.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.
|
||||
@@ -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.<site>.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 <port>`
|
||||
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) |
|
||||
@@ -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 |
|
||||
Reference in New Issue
Block a user