Cyd's point: a real pod bay console is its own machine, and every station
- pod, Live Cam, mission review - hears it over the wire. That is why the
spooler expects LoadMission and RunMission to arrive as packets. Ours is
colocated, and the network stack is quite right not to push bytes through
a socket to reach a client in the same process.
But the console had gone further than that. It called
application->Dispatch, stepping past the client's receive entry
altogether, so nothing watching packets ever saw the console speak. The
first Live Cam recording is the evidence: 14,342 packets, every one of
them from the racer via the interest manager, and not one LoadMission,
RunMission or StopMission - because those came from inside the house.
The tee was not in the wrong layer for the wire; it was in the right place
and the console was walking around it.
So build the packet SendWire would have built and hand it to the client's
own front door. NetworkClient::ReceiveNetworkPacket is Dispatch plus
whatever is watching, and Application IS the client for
ApplicationClientID, so this is the same delivery arriving where deliveries
arrive - no socket, no loopback, no second copy of the protocol.
Correcting myself twice over. RunMission does NOT have to be the first
packet in the spool: playback reads spool->GetPointer(), the current
cursor, by which time the task has consumed what came before, so it checks
that the cursor has REACHED RunMission rather than that the file starts
with it. And the ordering is therefore not "the whole job" as I claimed -
the recorded timings already show a normal shape, fifteen entity creations
inside the first twenty milliseconds and updates running from 0.110s to
308.940s of a five minute race.
Still open: the egg feed is local too (FeedLocalEgg), so a spool carries
no egg. Whether that matters depends on how the playback application loads
its mission, which is the next thing to find out rather than guess at.
WATCH ON NEXT LAUNCH: this changes how the local station is told to start
and stop a race. It should be identical - ReceiveNetworkPacket dispatches
the same message to the same object - but it is the launch path, so a race
that does not start is this commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>