Consider a dial-out transport mode: Amiga connects out to a configured host instead of listening

[sidick]

Context

Discussed while wrapping up phase 0.3 (#9, #10, #11): the wire protocol (server/WIRE.md) is transport-agnostic, line-oriented request/response over a byte stream. Nothing about it assumes which side initiates the TCP connection.

Right now (and as planned for 0.4's TCP transport) the model is host-as-client: AmiPilotServer binds/listens, and the host connects in when it wants to drive a test. That works standing at a real machine or under Copperline's bridged/loopback hostsocket networking (see the hostsocket session notes), but it doesn't fit NAT-mode emulation or a real Amiga behind NAT — there's no way for the host to reach in.

Proposal

A dial-out mode: AmiPilotServer periodically/persistently Connect()s out to a configured host:port (with reconnect/backoff) instead of listening, using bsdsocket.library the same way 0.4's inbound TCP transport would. The host runs a small listener and accept()s whichever configured Amigas check in, dispatching per-connection sessions. Framing and dispatch (server/WIRE.md, the shared HandleCommand) stay identical — this only changes which side initiates.

Bonus found during the pytest-plugin work (#11): this would also let the host side just block on accept() instead of the polling/retry-connect dance host/amipilot/pytest_plugin.py's _connect_with_retry currently has to do. Two real bugs were found and fixed there specifically because the host has to guess when the guest is ready (reconnect-per-attempt stranding replies on abandoned sockets; a VERSION sent before the guest opened its transport being silently dropped, not buffered). If the Amiga dials out only once its transport is genuinely open, accept() naturally blocks until that real moment — no polling, no premature-send race, no reconnect logic needed on either side.

Scope notes

• Needs a way to identify which Amiga just connected if a host might accept from more than one — likely a hostname/ID field added to the existing VERSION handshake payload.
• The host needs a persistent listener process rather than a dial-on-demand script — a different operational shape than today's "host drives one Amiga on demand" pytest fixture.
• Listen-mode (today's model) should stay available for the "walk up to a real Amiga and drive it standing there" case; this would be an additional mode, not a replacement.
• Natural fit for 0.4's TCP transport work, not a separate phase.

[sidick]

Concrete evidence for this from today's phase-0.4 TCP transport work (implementing the listen-mode side, #TBD): inbound access needs a real bridge setup — a macOS feth pair, /dev/bpf permissions, sudo, ARP occasionally needing a nudge — and over a long session of repeated Copperline boots against the same bridge, it degraded to the point where even ICMP ping to the guest started failing at 100% loss, with no config change on my end. Recreating the feth pair from scratch (destroy + rebuild, twice, with the user's sudo) didn't immediately fix it either.

None of this is a defect in the wire protocol or the TCP transport itself — a full clean round trip (VERSION/TYPE/GETTEXT/CLICK/TREE/QUIT) succeeded earlier in the same session with debug tracing confirming every internal step. It's specifically the bridge infrastructure required for inbound connections that's fragile and setup-heavy.

Dial-out avoids all of it: NAT mode needs no host bridge, no /dev/bpf, no sudo, and (per the emulator's own docs) is the simple, low-friction default — the guest just needs outbound connectivity, which NAT gives it unconditionally. This is exactly the "easier for most people to set up" case for real users too, not just this dev environment: asking someone to bridge a virtual NIC to a physical adapter (with the Wi-Fi caveats already noted in the project's Copperline notes) is a much bigger ask than "point the Amiga at a host:port."

Strengthens the case for prioritizing dial-out alongside (or ahead of) listen-mode polish in 0.4's TCP work.