ddidderr
09709cc008
Some games ship a SmartSteamEmu.ini somewhere under their installed
local/ tree with a `PersonaName = ...` line that must carry the player's
configured username. They also ship account_name.txt and language.txt
files that the launcher already overwrote with the username/language.
Previously that account_name.txt/language.txt overwrite happened inside
the install transaction, so it only applied to freshly (re)installed
games — games already installed by an older build never got fixed up,
and the SmartSteamEmu.ini PersonaName line was not handled at all.
This moves all per-user setting application out of install and into a
single one-shot step performed the first time a game is played, gated by
a new per-game marker `games/<id>/launch_settings_applied` under the
state dir. On first play we search the whole local/ tree and stamp:
- the username into the first account_name.txt,
- the language into the first language.txt,
- the username into the first SmartSteamEmu.ini PersonaName line,
preserving that line's existing line ending (\n or \r\n) and its
surrounding whitespace, leaving sibling lines untouched.
The marker only records that we *tried*: it is written unconditionally
after the first play, so a game with none of these files is still marked
done and never rescanned. Because already-installed games have no marker
yet, they are fixed up on their next play rather than only on reinstall.
To keep the marker honest across version changes, the install and update
transactions now clear it on success, so a freshly extracted local/ is
re-stamped on the next play.
Behavior changes from the user's perspective:
- The first time you press Play after this change, your username/
language are (re)applied to an existing install, including games you
installed before this feature existed.
- SmartSteamEmu.ini's PersonaName now reflects the launcher username.
Plumbing: account_name/language are removed from PeerCommand::InstallGame
/DownloadGameFiles[WithOptions] and the whole install handler chain, and
the Tauri pending_install_settings bookkeeping is gone — the launcher now
computes the values at play time in run_game and calls
lanspread_peer::apply_launch_settings_once. The headless harness gains a
`play` command exposing the same step for scripted testing.
Test Plan
- just test: new lanspread_peer::launch_settings unit tests cover the
PersonaName rewrite, \n/\r\n preservation, first-match search, the
unconditional marker, and the no-op-once-applied path; a transaction
test covers the install marker reset. Whole workspace is green.
- just clippy clean; the change adds no new clippy warnings (incl.
--tests).
- S38 (new in PEER_CLI_SCENARIOS.md): host run of lanspread-peer-cli
against the new fixture-persona/css RAR .eti (with --unrar) installs
css, then `play css` stamps the deeply-buried CRLF PersonaName line,
account_name.txt, and language.txt and creates the marker; a second
`play` is a no-op even after the values are reset externally.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
343 lines
29 KiB
Markdown
343 lines
29 KiB
Markdown
# Peer CLI P2P Scenarios
|
|
|
|
This matrix tracks the headless peer-to-peer contract exercised through
|
|
`lanspread-peer-cli`. It intentionally avoids the GUI and uses direct connect
|
|
for deterministic local runs; mDNS/macvlan remains an environment smoke path.
|
|
|
|
## Scenario Matrix
|
|
|
|
| ID | Scenario | Setup | Expected result |
|
|
| --- | --- | --- | --- |
|
|
| S1 | Startup scan | Start one peer with `fixture-alpha`. | Peer emits `local-peer-ready` and `local-library-changed`; catalog fixture games are `downloaded=true`, `installed=false`, `availability=Ready`. |
|
|
| S2 | Direct connect handshake | Start alpha and bravo, send alpha `connect` to bravo's ready address. | Both peers record one remote peer, no self-peer entry appears, and each peer receives the other's library. |
|
|
| S3 | Remote aggregation | Empty client connects to alpha and bravo. | `list-games` shows remote-only games once; shared `ggoo` has `peer_count=2`, unique games have `peer_count=1`. |
|
|
| S4 | Single-source download, no install | Empty client connected to bravo downloads `bfbc2` with `install=false`. | Client emits `got-game-files`, `download-begin`, `download-finished`, then local `bfbc2` is `downloaded=true`, `installed=false`; root files exist and `local/` does not. |
|
|
| S5 | Auto-install download | Empty client connected to bravo downloads `cnctw` with default install. | Download finishes, install begins and finishes, and local `cnctw` is `downloaded=true`, `installed=true` with `local/fixture-payload.txt`. |
|
|
| S6 | Manual install and uninstall | After S4, client sends `install bfbc2`, then `uninstall bfbc2`. | Install marks `bfbc2` installed and creates `local/`; uninstall removes `local/` while preserving downloaded root files. |
|
|
| S7 | Duplicate-source majority download | Empty client connects to alpha and bravo, then downloads shared `ggoo`. | Metadata from both peers validates by majority/plurality, download completes once, and installed state matches the install flag. |
|
|
| S8 | Ambiguous metadata rejection | Two peers advertise the same game/version with conflicting file sizes. | Download fails with a `download-failed` event; no committed `version.ini` is left for the target game. |
|
|
| S9 | Missing game | Client asks for a game none of its peers can serve. | CLI reports a deterministic command failure and emits `no-peers-have-game`; no local files are created. |
|
|
| S10 | Shutdown and goodbye cleanup | Alpha and bravo are connected, then bravo shuts down. | Alpha receives peer loss/removal and remote games from bravo disappear. |
|
|
| S11 | Same identity reconnect | Bravo restarts with the same state dir but a new port, then alpha connects to the new address. | Alpha has one bravo peer entry with the updated address, not duplicate identities. |
|
|
| S12 | Transfer serving gates | A peer has a non-catalog, missing-sentinel, active-operation, or `local/` path request. | The serving peer declines metadata/data; covered by unit tests where timing is too small for a stable CLI race test. |
|
|
| S13 | Exact transferred-file equality | Repeat small and large downloads, then compare every transferred regular file against its source with SHA-256 manifests. | Source and receiver manifests match exactly for each transferred file; no extra or missing files appear in the downloaded game root. |
|
|
| S14 | Large multi-peer chunked download | `fixture-alpha/alienswarm` contains a renamed RAR `.eti` larger than 100 MB. A second peer downloads it, then a third peer downloads `alienswarm` from both peers. | The third peer's downloaded files match the source by SHA-256; `download-chunk-finished` events show the large `.eti` chunks coming from both peers with byte counts balanced within one chunk. |
|
|
| S15 | Three-way version skew | Three peers advertise the same catalog game ID. Peer A has `version.ini=20250101`, peer B has `version.ini=20250201`, and peer C has `version.ini=20250301`; each version has distinguishable file contents. An empty client connects to all three and downloads the game with `install=false`. | `list-games` shows one row for the game with `peer_count=3` and `eti_game_version=20250301`. The `got-game-files` descriptor set and transfer source are peer C's newest version only; no chunks come from A or B. The receiver's `version.ini` and SHA-256 manifest match C exactly. |
|
|
| S16 | Latest-version fanout with stale peers present | Peer A has an older version of a game. Peers B and C both advertise the same newest version with matching file manifests; use a large file when proving chunk split. | The aggregated row still counts all ready peers, but eligible transfer peers are only B and C. Large-file chunks may split between B and C; peer A contributes no manifest majority vote and no file chunks. |
|
|
| S17 | Latest-version conflict rejection | Peer A has an older version. Peers B and C both advertise the newest version, but their latest-version file sizes conflict. | Validation considers only the latest-version peers, so A cannot rescue the majority. The download fails with `download-failed`, and no committed target `version.ini` remains. |
|
|
| S18 | Mid-download source drop with redundancy | Client downloads a large shared game from two ready peers, then one source is killed after the download has begun. | Failed chunks are retried against the surviving source; the download finishes, no `download-failed` is emitted, and the receiver's files match the source by diff or SHA-256. |
|
|
| S19 | Mid-download sole-source drop | Client downloads a large game from one source, then that source is killed after the download has begun. | The download emits `download-failed`; no committed target `version.ini` remains; any partial payload is not advertised as ready; active operation state clears so a retry is possible. |
|
|
| S20 | Receiver write failure | Client downloads a large game into a constrained `/games` filesystem. | The download fails deterministically, no committed `version.ini` is advertised, and active operation state clears so the peer can retry later. |
|
|
| S21 | Add-game propagation | Two connected peers are running; one peer gains a new catalog game root through a completed download or an external drop. | The other peer receives a library update without reconnecting, and `list-games` shows the new remote game under the existing peer. |
|
|
| S22 | Remove-game propagation | Two connected peers are running; one peer loses a previously advertised game root. | The other peer receives a library update without dropping the peer, and `list-games` no longer shows that remote game. |
|
|
| S23 | Version bump propagation | Two connected peers are running; one peer's ready game root gets a newer `version.ini`. | The other peer receives a library update without reconnecting, and the aggregated row reflects the newer `eti_game_version`. |
|
|
| S24 | Two clients pull from one source | Two empty clients connect to the same source and download the same large game concurrently. | Both downloads finish, both receivers match the source by diff or SHA-256, and the source remains responsive. |
|
|
| S25 | One client downloads two games concurrently | One client connected to a source issues two different `download` commands without waiting for the first to finish. | Both operations may run in parallel; both eventually finish, each game reaches the requested install state, and each transferred root matches its source. |
|
|
| S26 | Same-game duplicate download rejection | A client starts downloading a game, then issues a second `download` command for the same game while the first operation is active. | The second request is rejected deterministically as an operation-in-progress condition; the first download is not corrupted and still reaches its documented final state. |
|
|
| S27 | Self-connect rejection | A peer sends `connect` to its own advertised listener address. | The command fails cleanly, no self-peer entry is created, and the peer remains responsive. |
|
|
| S28 | Address change without identity change | A known peer is rediscovered with the same peer ID and a different listener address while its library is still known. | The peer record updates in place to the new address, the existing library stays attached to that peer ID, and no duplicate peer entry appears. This is covered with a deterministic unit-level check until the CLI can rebind a live listener without restart. |
|
|
| S29 | Empty-library peer participates | A peer with no games connects into the mesh. | Other peers list it as a peer with zero games; it can receive a download, advertise the new game without restart, and become a source. |
|
|
| S30 | 5+ peer mesh aggregation | Five peers advertise partially overlapping catalog games with a mix of unique games, shared games, and differing versions; a sixth client connects to all five. | The client shows one row per game ID, correct ready-source `peer_count`, latest `eti_game_version`, no duplicates, and no self entries. |
|
|
| S31 | Bootstrapped peer becomes source in same session | An empty client downloads a game from a source, the original source shuts down, then a fresh third peer downloads the same game from the bootstrapped client. | The third peer's files match the original source by diff or SHA-256, proving downloaded files become servable without restart. |
|
|
| S32 | Reinstall after uninstall | A downloaded game is installed, uninstalled, then installed again without another download. | `local/` is recreated from preserved root files, no transfer events occur during reinstall, and the game returns to `installed=true`. |
|
|
| S33 | Install after external root mutation | A downloaded game root is externally mutated before `install` is issued. | The CLI fixture installer installs from the current root bytes. The resulting `local/fixture-payload.txt` must match the mutated archive bytes exactly. |
|
|
| S34 | Many-small-files game without `.eti` | A catalog game root contains `version.ini` plus many small regular files and no archive. | Download with `install=false` transfers every file, chunk events are coherent for small files, and source/receiver manifests match exactly. |
|
|
| S35 | Unknown game ID from remote peer | A remote peer advertises a game ID that is not in the receiver's catalog. | The receiver does not list the unknown game as downloadable, download attempts fail deterministically, and no local files are created. |
|
|
| S36 | Latest singleton beats stale majority | Five peers advertise one game; one peer has `20260501`, four peers have `20250101`. | `list-games` reports `eti_game_version=20260501`; all descriptors and chunks come from the singleton latest peer; stale peers contribute zero bytes. |
|
|
| S37 | Single-source download throughput | A source peer advertises a temporary catalog game with one sparse `2 GiB` `.eti`; an empty client downloads it with `install=false`. | The client emits `download-finished` with throughput measurements (`bytes`, `duration_ms`, `mib_per_s`, `mbit_per_s`), and the downloaded archive size matches the source. |
|
|
| S38 | First-play launch-setting stamping | `fixture-persona/css` ships a real RAR `.eti` whose tree buries a CRLF `SmartSteamEmu.ini` with a stub `PersonaName` line under `engine/bin/win64/steam_settings/`, plus a stub `account_name.txt` and `language.txt` under `profiles/local/`. A peer installs `css` (with `--unrar`), then sends `play css` with a username and language, then `play css` again. | After install the marker `games/css/launch_settings_applied` is absent and the stub files are intact under `local/`. The first `play` returns `already_applied=false` with `account_name_written`, `language_written`, and `persona_name_written` all true; the deep `SmartSteamEmu.ini` `PersonaName` value becomes the username with its `\r\n` ending and sibling lines preserved, `account_name.txt` becomes the username, `language.txt` becomes the passed language, and the marker now exists. A second `play` returns `already_applied=true`, rewrites nothing, and leaves the files untouched even if their values were reset externally. |
|
|
|
|
## Version-Skew Contract
|
|
|
|
Use S15-S17 to pin down what "newer" means when several peers have the same
|
|
game ID:
|
|
|
|
- Version comparison uses the eight-digit `version.ini` string, so use sortable
|
|
`YYYYMMDD` values in manual fixtures.
|
|
- `list-games` aggregates by game ID. The game appears once; `peer_count`
|
|
counts all ready peers with that ID, including peers that only have older
|
|
versions.
|
|
- The aggregated `eti_game_version` must be the newest ready version.
|
|
- The descriptor set emitted to the download path, file-size validation, and
|
|
transfer planning are latest-only. Older-version peers may be queried by a
|
|
generic detail request, but their descriptors must not supply download
|
|
descriptors, majority votes, or chunks once a newer version exists.
|
|
- If exactly one peer has the latest version, that peer is the only transfer
|
|
source. If several peers tie on the latest version, validation and chunk
|
|
fanout happen among that latest-version set only.
|
|
- Capture proof with the `list-games` row, `got-game-files` descriptors,
|
|
`download-chunk-finished` source addresses, and source/receiver SHA-256
|
|
manifests.
|
|
|
|
## Extended Failure And Mutation Contracts
|
|
|
|
Use S18-S36 to pin down operational behavior that is awkward to prove with the
|
|
GUI:
|
|
|
|
- A failed download must not commit the root `version.ini` sentinel. Partial
|
|
payload files may remain, but they must not be advertised as a ready local
|
|
game and must not leave an active operation stuck.
|
|
- Source failure during a redundant download should retry failed chunks against
|
|
another validated source for the same latest-version file.
|
|
- Live local library changes are observable by connected peers through library
|
|
deltas; reconnect is not required for add, remove, or version-bump cases.
|
|
- Same-game operations are single-flight. A duplicate download request while a
|
|
game is already active is rejected instead of starting another writer.
|
|
- Unknown remote game IDs are filtered by the receiver's current catalog and
|
|
are not downloadable.
|
|
|
|
For a manual run, prefer a catalog game ID already served by the fixture lab,
|
|
such as `cnc4`, then create temporary `just peer-cli-run` game roots with
|
|
different `version.ini` contents. The existing alpha/bravo/charlie fixtures
|
|
cover duplicate-source and shared-game cases, but not the three-version skew
|
|
until a dedicated fixture or temporary games root is prepared.
|
|
|
|
## First-Play Launch-Setting Contract
|
|
|
|
Use S38 to pin down how launcher settings are stamped into an installed game:
|
|
|
|
- Stamping happens on the first `play`, not during install/update. The install
|
|
transaction only clears the `games/<id>/launch_settings_applied` marker so the
|
|
next play reapplies settings to a freshly (re)created `local/`.
|
|
- The first play stamps the username into the first `account_name.txt` and the
|
|
first `SmartSteamEmu.ini` `PersonaName` line, and the language into the first
|
|
`language.txt`, searching the whole `local/` tree. The matched `PersonaName`
|
|
line keeps its existing line ending (`\n` or `\r\n`).
|
|
- The marker records only that we *tried*: it is written unconditionally after
|
|
the first play, so a game with none of these files is still marked done.
|
|
- S38 needs a real archive expanded with `--unrar`, so it runs against the host
|
|
`lanspread-peer-cli` binary rather than the Docker matrix image (which omits
|
|
`unrar`). The peer crate's `launch_settings` unit tests cover the rewrite,
|
|
line-ending, and marker logic deterministically.
|
|
|
|
## Run Log
|
|
|
|
### 2026-05-28 - First-Play Launch-Setting Stamping (S38)
|
|
|
|
- Code under test moved the `account_name.txt`/`language.txt` overwrite out of
|
|
the install transaction and into a single first-play step (shared with the new
|
|
`SmartSteamEmu.ini` `PersonaName` rewrite) gated by the
|
|
`games/<id>/launch_settings_applied` marker.
|
|
- `just test` passed the whole workspace, including the new
|
|
`lanspread_peer::launch_settings` unit tests and
|
|
`install::transaction::install_resets_launch_settings_marker`.
|
|
- S38 host run: built `crates/lanspread-peer-cli/fixtures/fixture-persona/css`
|
|
with a stored RAR `.eti` (verified by `unrar t`) burying a CRLF
|
|
`SmartSteamEmu.ini` plus stub `account_name.txt`/`language.txt`. A host peer
|
|
installed `css` with `--unrar /usr/bin/unrar`, then `play css` stamped the
|
|
username into the deep `PersonaName` line (CRLF preserved, sibling lines
|
|
intact) and `account_name.txt`, the language into `language.txt`, and created
|
|
the marker. A second `play css` returned `already_applied=true` and rewrote
|
|
nothing even after the value was reset externally.
|
|
|
|
### 2026-05-19 - Snapshot Status Fix Docker Matrix Pass
|
|
|
|
- Code under test included `5c4976d` (`fix(peer): settle local state before
|
|
clearing operations`) and `6651f02` (`fix(ui): derive operation status from
|
|
snapshots`).
|
|
- Gates before the matrix: `just fmt`, `just test`, `just frontend-test`, and
|
|
`just build` passed. The peer harness image was rebuilt with
|
|
`just peer-cli-image`.
|
|
- Runner: `python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
|
|
passed S1-S36 against the rebuilt `lanspread-peer-cli:dev` image.
|
|
- Auto-install coverage remained good: S5 downloaded and installed `cnctw`, saw
|
|
the fixture payload under `local/`, and the downloaded root diffed cleanly
|
|
against `fixture-bravo/cnctw` excluding local metadata.
|
|
- Large/exact transfer coverage remained good: S13 small and large downloads
|
|
diffed cleanly; S14 split `alienswarm` between two sources with chunk totals
|
|
`67,108,864` and `58,721,049` bytes and the final root diffed cleanly.
|
|
- Failure and mutation coverage remained good: S17 latest-version conflict,
|
|
S19 sole-source drop, S20 write failure, S26 duplicate operation, and S35
|
|
unknown catalog filtering all failed safely without advertising bad local
|
|
state; S21-S23 propagation, S24-S25 concurrency, S29-S31 bootstrapping, S32
|
|
reinstall, S33 mutation install, S34 many-small-files, and S36 latest
|
|
singleton all passed.
|
|
|
|
### 2026-05-18 - Full Automated Docker Matrix Pass
|
|
|
|
- Runner: `python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
|
|
passed S1-S36 against the current `lanspread-peer-cli:dev` image.
|
|
- S1-S17 rerun highlights: startup, direct connect, aggregation, download,
|
|
install/uninstall, duplicate-source, ambiguous metadata, missing game,
|
|
shutdown cleanup, identity reconnect, serve gates, exact equality, large
|
|
multi-peer chunking, and latest-version selection/conflict all passed. Exact
|
|
transfer scenarios used `diff -r`/SHA-256 manifest checks; S14 chunk totals
|
|
were `58,721,049` and `67,108,864` bytes, balanced within one `32 MiB` chunk.
|
|
- S18-S36 rerun highlights: source-drop, disk-full, live mutation, concurrency,
|
|
duplicate-operation rejection, self-connect rejection, empty-peer sourcing,
|
|
5-peer aggregation, bootstrapped sourcing, reinstall, external mutation,
|
|
many-small-files, unknown catalog filtering, and stale-majority/latest
|
|
singleton cases all passed. File-copy scenarios used diff/manifests or `cmp`
|
|
for the mutated install payload.
|
|
|
|
### 2026-05-18 - Extended Scenario Docker Pass
|
|
|
|
- Runner: `python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
|
|
passed for S18-S36 after rebuilding `lanspread-peer-cli:dev` with
|
|
`just peer-cli-image`.
|
|
- S18 redundant source drop: one `alienswarm` source was killed after
|
|
`download-begin`; the client emitted `download-finished`, no
|
|
`download-failed`, and `diff -r`/SHA-256 manifest comparison matched the
|
|
surviving source. Recorded large-file chunk bytes from the surviving source:
|
|
`58,721,049`.
|
|
- S19 sole-source drop: killing the only source after `download-begin` emitted
|
|
`download-failed`; the receiver had no committed `alienswarm/version.ini`, no
|
|
ready local row, and no active operation left.
|
|
- S20 receiver write failure: a client with `/games` constrained to a `32m`
|
|
tmpfs emitted `download-failed`; `/games/alienswarm/version.ini` was absent
|
|
inside the container and active operations were empty.
|
|
- S21-S23 live mutation propagation: a connected peer observed `cod5` added,
|
|
`cod5` removed, and `cnc4` bumped from `20250101` to `20260501` without
|
|
reconnecting or dropping the peer.
|
|
- S24-S25 concurrency: two clients downloaded `alienswarm` from one source at
|
|
the same time and both diffed cleanly; one client downloaded `bfbc2` and
|
|
`cnctw` concurrently and both roots diffed cleanly.
|
|
- S26 duplicate same-game download: the second `alienswarm` download command
|
|
returned `operation already in progress for game alienswarm`; the first
|
|
download still finished and diffed cleanly.
|
|
- S27 self-connect rejection: connecting a peer to its own listener returned
|
|
`cannot connect peer to itself ...`; `list-peers` stayed empty and the peer
|
|
stayed responsive.
|
|
- S28 address-change invariant: `just test` passed and included
|
|
`peer_db::tests::address_update_preserves_peer_identity_and_library`.
|
|
- S29 empty-library peer: an observer first saw the empty peer with zero games;
|
|
after that peer downloaded `alienswarm`, the downloaded root diffed cleanly
|
|
and the observer's peer snapshot for that same peer contained `alienswarm`.
|
|
- S30 5-peer aggregation: a sixth client connected to five peers and aggregated
|
|
six game IDs with expected `peer_count` and latest versions, with no duplicate
|
|
game rows and no self-peer entry.
|
|
- S31 bootstrapped source: after the original source was killed, a third peer
|
|
downloaded `alienswarm` from the bootstrapped client and diffed cleanly
|
|
against the original fixture.
|
|
- S32 reinstall: reinstall after uninstall recreated `local/`, reported
|
|
`installed=true`, and produced no transfer chunk events during reinstall.
|
|
- S33 external root mutation: after mutating the downloaded `bfbc2.eti` inside
|
|
the client container, `install` wrote `local/fixture-payload.txt` that matched
|
|
the mutated archive exactly by `cmp`.
|
|
- S34 many-small-files transfer: a `bf1942` fixture with 20 small regular files
|
|
and no `.eti` downloaded with `install=false`; 21 file chunks were observed
|
|
including `version.ini`, and the receiver diffed cleanly against the source.
|
|
- S35 unknown game ID: a source advertised `mystery-game` via `--fixture`; the
|
|
receiver filtered it out of `list-games`, `download mystery-game` returned
|
|
`game mystery-game is not in the local catalog`, and no local files were
|
|
created.
|
|
- S36 latest singleton: with one peer on `20260501` and four peers on
|
|
`20250101`, the client reported `peer_count=5` and latest `20260501`; only
|
|
the singleton latest peer sent chunks and the final root diffed cleanly.
|
|
|
|
### 2026-05-18 - Full Matrix Manual Docker Pass
|
|
|
|
- Build/setup: `just peer-cli-image` passed. Local `just peer-cli-build`
|
|
needed `RUSTC_WRAPPER=` because the host `kache` wrapper failed with a
|
|
read-only filesystem error; `RUSTC_WRAPPER= just peer-cli-build` passed.
|
|
- Temporary skew/conflict fixtures were created under the ignored
|
|
`.lanspread-peer-cli/full-fixtures/` tree using `rar a -idq -m0` against
|
|
`/dev/urandom` payloads and then renaming the archives to `.eti`.
|
|
`find .lanspread-peer-cli/full-fixtures -name '*.eti' -exec unrar t -idq {} \;`
|
|
passed.
|
|
- S1 startup scan: `just peer-cli-alpha` emitted `cli-started`,
|
|
`local-library-changed`, and `local-peer-ready`; `alienswarm`, `bf1942`, and
|
|
`ggoo` were `downloaded=true`, `installed=false`, `availability=Ready`.
|
|
- S2 clean direct connect: with only alpha and bravo running, alpha connected to
|
|
bravo at `10.66.0.3:42776`; `wait-peers` returned `peer_count=1`, and
|
|
`list-peers` showed exactly one bravo peer with four games.
|
|
- S3 clean remote aggregation: an empty `clean-s3-client` saw exactly alpha and
|
|
bravo. `list-games` showed `ggoo peer_count=2`; `alienswarm`, `bf1942`,
|
|
`bfbc2`, `cnc4`, and `cnctw` each had `peer_count=1`.
|
|
- S4 single-source no-install: `full-empty-client` downloaded `bfbc2` from
|
|
bravo with `install=false`. Events included `got-game-files`,
|
|
`download-begin`, `download-finished`, and local `installed=false`. Host
|
|
verification: `diff -r crates/lanspread-peer-cli/fixtures/fixture-bravo/bfbc2
|
|
.lanspread-peer-cli/full-empty-client/games/bfbc2` passed and `local/` was
|
|
absent.
|
|
- S5 auto-install: `full-empty-client` downloaded `cnctw` with default install.
|
|
Events included download finish, `install-begin`, and `install-finished`;
|
|
`local/fixture-payload.txt` existed. Host verification diffed the downloaded
|
|
files against `fixture-bravo/cnctw` excluding `local/` and `.lanspread.json`.
|
|
- S6 manual install/uninstall: after S4, `install bfbc2` created `local/` and
|
|
marked `installed=true`; `uninstall bfbc2` removed `local/` and preserved the
|
|
downloaded root files. Host verification diffed the preserved files against
|
|
`fixture-bravo/bfbc2` excluding `.lanspread.json`.
|
|
- S7 duplicate-source download: `full-empty-client` downloaded shared `ggoo`
|
|
from alpha/bravo with `install=false`. Chunk events used alpha for
|
|
`version.ini` and bravo for `ggoo.eti`; host `diff -r` matched both
|
|
`fixture-alpha/ggoo` and `fixture-bravo/ggoo`.
|
|
- S8 ambiguous metadata rejection: `full-s8-a` and `full-s8-b` both advertised
|
|
`ggoo` version `20260101` but with different `.eti` sizes (`1,048,746` and
|
|
`2,097,323` bytes). The client saw `peer_count=2`, then `download ggoo`
|
|
emitted `download-failed`; no target `ggoo/version.ini` was committed.
|
|
- S9 missing game: `download does-not-exist` emitted `no-peers-have-game` and
|
|
returned a command error; `.lanspread-peer-cli/full-empty-client/games` had no
|
|
`does-not-exist` directory.
|
|
- S10 shutdown cleanup: alpha saw bravo before shutdown with one remote peer and
|
|
bravo-only remote games. After bravo `shutdown`, alpha emitted `peer-lost`;
|
|
`list-peers` returned `[]` and `list-games` returned an empty remote list.
|
|
- S11 same identity reconnect: restarting bravo reused peer ID
|
|
`019e347d901e70c19adf5b9fd313fce4` at new address `10.66.0.3:41764`.
|
|
Alpha `list-peers` showed exactly one bravo entry at the new address.
|
|
- S12 transfer serving gates: this remains covered by unit tests because the
|
|
CLI cannot stably race raw transfer requests against non-catalog, missing
|
|
sentinel, active-operation, and `local/` path states. `RUSTC_WRAPPER= just
|
|
test` passed, including `local_download_available_gates_on_catalog_operation_and_sentinel`,
|
|
`get_game_response_respects_serve_gates`,
|
|
`file_transfer_dispatch_respects_serve_gates`, and
|
|
`local_relative_paths_are_never_transferable`.
|
|
- S13 exact transferred-file equality: the S4 small transfer and S14 large
|
|
transfer both passed host `diff -r` against the original source game
|
|
directories, proving exact file equality beyond event flow.
|
|
- S14 large multi-peer chunked download: `full-empty-client` first downloaded
|
|
`alienswarm` from alpha and diffed cleanly against `fixture-alpha/alienswarm`.
|
|
A fresh `full-s14-client` then saw `alienswarm peer_count=2` and downloaded
|
|
from both alpha and `full-empty-client`. Large `.eti` chunk totals were
|
|
`67,108,864` bytes from alpha and `58,721,049` bytes from the staged peer,
|
|
balanced within one `32 MiB` chunk. Final host `diff -r` against
|
|
`fixture-alpha/alienswarm` passed.
|
|
- S15 three-way version skew: peers A/B/C advertised `cnc4` versions
|
|
`20250101`, `20250201`, and `20250301`. The client saw one row with
|
|
`peer_count=3` and `eti_game_version=20250301`; all chunks came only from C
|
|
at `10.66.0.4:60290`. Host `diff -r` against C passed.
|
|
- S16 latest-version fanout with stale peer present: A advertised stale
|
|
`20250101`; B/C both advertised latest `20250301` with a `134,217,906` byte
|
|
`.eti`. The client saw `peer_count=3`; chunks came only from B/C
|
|
(`67,108,873` and `67,109,042` bytes respectively), with stale A contributing
|
|
zero. Host `diff -r` matched both B and C.
|
|
- S17 latest-version conflict rejection: A advertised stale `20250101`; B/C
|
|
both advertised latest `20250301` but with conflicting `.eti` sizes
|
|
(`1,048,748` and `2,097,325` bytes). The client saw `peer_count=3` and latest
|
|
`20250301`, then `download cnc4` emitted `download-failed`; no target
|
|
`cnc4/version.ini` was committed.
|
|
- Gates after manual runs: `just fmt`, `RUSTC_WRAPPER= just test`, and
|
|
`RUSTC_WRAPPER= just clippy` passed.
|
|
|
|
### 2026-05-17 - Exact Transfer And Large Multi-Peer Chunking
|
|
|
|
- Fixture update: `fixture-alpha/alienswarm/alienswarm.eti` was rebuilt with
|
|
`rar a -idq -m0` from three random 40 MiB payload files, then renamed to
|
|
`.eti`. Final archive size: `125,829,913` bytes. `unrar t -idq` passed.
|
|
- Gates before manual runs: `just fmt`, `just test`, `just peer-cli-build`,
|
|
`just clippy`, and `just peer-cli-image` passed.
|
|
- S13 small exact transfer: `deep-small-client` downloaded `bfbc2` from
|
|
`fixture-bravo` with `install=false`. SHA-256 manifests matched exactly:
|
|
`bfbc2/bfbc2.eti`
|
|
`f7accef0833f29481acdeaac58261bc4fc23ebb58b7197049024d354f60daabc`;
|
|
`bfbc2/version.ini`
|
|
`f3d94f70edcebbbc7d8ce38fdf076412fb95114ce1ecf071b26c9c2f93586372`.
|
|
- S13 large exact transfer: `deep-stage-b` downloaded `alienswarm` from
|
|
`fixture-alpha` with `install=false`. SHA-256 manifests matched exactly:
|
|
`alienswarm/alienswarm.eti`
|
|
`8a4fb1fd458e731affb175134b7b99efc8d8a5eda80e978ba81f721d01aecc43`;
|
|
`alienswarm/notes.txt`
|
|
`3832bcb7057a4453981e975d2d2d528bfd9a26671423352f4a8527362d5b9810`;
|
|
`alienswarm/version.ini`
|
|
`8dfdc51d4dbfb06015b41a85a5f5d47f44144139e4a12db2b17eb040773082a3`.
|
|
- S14 multi-peer setup: `deep-stage-c` connected to alpha
|
|
(`10.66.0.3:53514`) and `deep-stage-b` (`10.66.0.2:58491`). `list-games`
|
|
showed `alienswarm` with `peer_count=2` before the download.
|
|
- S14 chunk-source evidence for `alienswarm/alienswarm.eti`: `deep-stage-c`
|
|
received chunks from `deep-stage-b` at offsets `0` and `67,108,864`
|
|
(`67,108,864` bytes total) and from alpha at offsets `33,554,432` and
|
|
`100,663,296` (`58,721,049` bytes total). The source-byte difference was
|
|
`8,387,815` bytes, below one `32 MiB` chunk.
|
|
- S14 final exactness: `deep-stage-c`'s `alienswarm` SHA-256 manifest matched
|
|
`fixture-alpha` exactly for `alienswarm.eti`, `notes.txt`, and `version.ini`.
|