funman300
a9eb54ae9c
Third migration step, and the one that turns fixture parity into transport parity. A TCP host that frames a Fire2 stream, keeps one Session per connection, calls openfut-adapter-fifa17::dispatch(), and writes the returned frames in order. It owns a socket, a buffer, a session and diagnostics -- that is the complete list. No coins, club, packs, profiles or UTAS logic: those belong to Core, reached through the adapter later. NO TLS, and that is evidence-based rather than an omission. The Blaze main port is plaintext: sending a raw Fire2 Util::ping to the running backend returns a plaintext PingResponse, blaze_handle uses the raw socket, and only redir_handle wraps ssl. TLS belongs to the redirector phase. LIVE A/B AGAINST THE RUNNING PYTHON BACKEND: 101 frames across three conversations, identical normalized traces. This is the first result in the migration that is not purely offline. check-live-parity.sh replays the recorded conversations against both endpoints over real sockets and diffs volatile-masked traces; session keys and clocks are masked, so anything that differs is behavioural. Transport tests cover what fixtures cannot: byte-for-byte replay over a socket, requests dribbled one byte at a time, several requests in one write, the four-frame login burst ordered on the wire, session state persisting across frames and NOT leaking between connections, an absurd payload length closing the connection instead of allocating, and an undecodable body still getting a reply. 18 tests here, 116 across the three migration crates. MUTATION TESTED, including the comparison itself. Dropping a post-login notification is caught by the probe (frame count) AND the diff; a same-length content change deep inside a notification body (CTY "US"->"GB", payload 116 both sides) is caught ONLY by the trace digest. So the probe's exit code is not the test -- the diff is, and the README says so. check-live-parity.sh was itself verified to exit 1 under mutation. The listen port is required configuration with no default, so the sidecar cannot silently collide with the working container. OPENFUT_BIND stays the advertised-config bind (the adapter derives nucleusConnect from it, reproducing the oracle) and the listener gets its own setting, so the two are not conflated. Gates 1-4 pass and are re-runnable. Gates 5-10 need a FIFA client and are listed in the README, including the Python -> Rust -> Python -> Rust back-and-forth that proves the rollback path rather than asserting it. Python backend untouched and still the live runtime; contract suite 446/446 after this work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
openfut-blaze-host
A deliberately thin TCP host for the FIFA 17 Blaze RPC surface. Runs beside the working Python backend, never instead of it.
listener → Fire2 stream framing → per-connection Session
│
openfut-adapter-fifa17::dispatch
│
write returned frames, in order
Scope
Owns: a socket, a read buffer, one Session per connection, diagnostics.
That is the complete list.
Must never acquire: coins, club state, packs, profiles, market state, UTAS logic. Those belong to OpenFUT Core, reached later through the adapter. A transport host that starts holding game state becomes a second backend — the architecture this migration exists to avoid.
No TLS
The Blaze main port is plaintext. Verified against the running Python
backend by sending a raw Fire2 Util::ping and getting a plaintext
PingResponse back; blaze_responder_v3b.py::blaze_handle uses the raw socket
and only redir_handle wraps ssl. TLS belongs to the redirector phase.
Running it
Both critical settings are required — there is no default port anywhere in this crate, so it cannot silently collide with the Python container.
cargo build -p openfut-blaze-host
OPENFUT_ADVERTISE=<backend LAN ip> \
OPENFUT_BIND=0.0.0.0 \
POW_CONTENT_HOST=<backend LAN ip>:8085 \
OPENFUT_BLAZE_HOST_BIND=0.0.0.0 \
OPENFUT_BLAZE_HOST_PORT=<free port> \
OPENFUT_BLAZE_TRACE=/tmp/rust-blaze.trace \
./target/debug/openfut-blaze-host
OPENFUT_BIND is the advertised-config bind, not the listener's. The
adapter derives nucleusConnect from it (reproducing the oracle — see the
adapter README and the vault's known-issue entry), so it must mirror whatever
the Python container runs with, or the two will not compare. The listener has
its own OPENFUT_BLAZE_HOST_BIND.
For a FIFA test from another machine, OPENFUT_BLAZE_HOST_BIND must be 0.0.0.0
(or the LAN address); the default follows OPENFUT_BIND.
Live A/B against Python
./check-live-parity.sh 127.0.0.1:42130 127.0.0.1:<rust port>
Replays the recorded conversations against both endpoints over real sockets and diffs the normalized traces. Session keys and server timestamps are masked, so anything that differs is a real behavioural difference.
The diff is the test, not the probe's exit code. The probe only detects anomalies visible live — missing frames, an early close. A same-length content change deep inside a notification body shows up only as a digest difference in the trace. Both cases were verified by mutation.
For the comparison to mean anything both servers must run the same config —
same OPENFUT_ADVERTISE, OPENFUT_BIND, POW_CONTENT_HOST and active persona
— or legitimate config differences read as parity failures.
Current result against the live container:
main: IDENTICAL (82 frames)
fallbacks: IDENTICAL (12 frames)
locale: IDENTICAL (7 frames)
LIVE PARITY OK — 101 frames, identical normalized traces.
Tests
cargo test -p openfut-blaze-host — 18 tests. The integration suite runs the
real host on an ephemeral port and replays the recorded conversations over TCP,
covering what fixtures cannot:
- byte-for-byte replay over a socket
- requests dribbled one byte at a time (fragmentation)
- several requests in one write (coalescing)
- the four-frame login burst arriving in order on the wire
- session state persisting across frames, and not leaking between connections
- an absurd payload length closing the connection instead of allocating
- an undecodable body still getting a reply
Byte-exactness is possible only because Hooks injects the session key and
clock — they appear inside response bodies, so with the real ones no live run
could reproduce a recording. That is the crate's only test seam.
Promotion gates
Automated, re-runnable now:
- ✅ All migration tests pass (116 across the three crates).
- ✅ Python contract suite still 446/446.
- ✅ Scripted connection to the Rust host succeeds.
- ✅ Recorded conversations work through the real TCP host, and the live A/B against Python is identical over 101 frames.
Requiring a FIFA client on the game machine — not yet done:
- ⬜ FIFA reaches FUT with Rust Blaze.
- ⬜ Close FIFA completely.
- ⬜ FIFA reaches FUT a second time.
- ⬜ Restore Python Blaze and confirm rollback works.
- ⬜ Switch back to Rust and confirm again.
- ⬜ Only then is Rust Blaze a viable runtime replacement.
Gates 8 and 9 matter as much as 5: Python → Rust → Python → Rust proves the
rollback path rather than asserting one exists.
Running gate 5
Keep the Python container exactly as it is. On the game machine, redirect only the Blaze destination to the sidecar's port; the redirector, Nucleus, roster, UTAS and POW keep hitting Python. The single changed variable is then Python Blaze vs Rust Blaze.
The redirector is what tells the client where Blaze lives, so the cleanest switch is to point the Python redirector's advertised Blaze port at the sidecar rather than reconfiguring the client.
Diagnostics
The log mirrors the Python responder's shape so the two can be read side by side: connection id, peer, frame number, route, msgType, msgNum, userIndex, options, payload and metadata sizes, every response emitted, and a close reason.
OPENFUT_BLAZE_TRACE=<path> additionally writes the normalized structural
trace — the same format the probe emits, so a live FIFA session against Rust can
be diffed against one against Python.
No credential or token is logged. Volatile values are replaced before they reach the line, not truncated after, and a test asserts a known secret never appears in trace output.