Pat currently initializes and stores stateful modem transports directly on App. Listening and outbound connections obtain these modems through transport-specific accessors such as VARAHF() and VARAFM(), while initialization, health checks, reuse, CAT/VFO handling, and cleanup are spread across App, Connect, and ListenerHub.
This becomes increasingly difficult to manage as additional modem implementations and orchestration mechanisms are added:
ListenerHub already implements part of the desired pattern for listener mode. It manages transport listeners by name, initializes them through TransportListener, retries failed listeners, tracks active listeners, and closes them centrally. VARA HF and FM listeners participate in this model through the existing VARAHF() and VARAFM() accessors.
However, ListenerHub is intentionally focused on listener accept loops. It does not manage the lifecycle or ownership of the underlying modem instances, particularly when the same modem is shared between listener mode and outbound connections. A complementary modem lifecycle abstraction would preserve ListenerHub's current responsibility while providing consistent initialization, reuse, acquisition, and cleanup beneath both listening and dialing.
PR #542 demonstrates why lifecycle ownership needs to be explicit. A modem may be shared by an active listener and an outbound connection, but the current proposal tracks Varanny sessions by transport scheme and performs cleanup directly in Connect. This allows one user of a modem to stop resources still needed by another and requires transport-specific cleanup at numerous return paths.
Introduce a lifecycle abstraction, tentatively called ModemHub, for stateful modem transports.
Relationship to ListenerHub
ListenerHub should remain responsible for:
- Enabling and disabling listeners.
- Running listener accept loops.
- Retrying failed listeners.
- Tracking active listeners.
- Listener-specific behavior such as beacons.
The modem lifecycle abstraction should complement ListenerHub by managing the underlying stateful resources used by listeners and outbound connections:
- Modem initialization and health checks.
- Reuse between listeners and outbound connections.
- Ownership or lease tracking.
- Associated CAT/VFO resources.
- Implementation-specific startup and shutdown.
- Application-wide cleanup.
Listeners would acquire their modem through the same lifecycle abstraction as outbound connections, while ListenerHub would continue managing the resulting net.Listener and accept loop.
Responsibilities
The modem lifecycle abstraction should:
- Initialize modems on demand.
- Reuse healthy modem instances.
- Track ownership across listeners and outbound connections.
- Prevent one user from closing a modem that is still in use elsewhere.
- Manage resources associated with a modem, such as CAT/VFO connections.
- Provide a consistent acquisition and release lifecycle.
- Close managed resources during application shutdown.
- Support different modem implementations and provisioning mechanisms.
- Keep transport-specific lifecycle state out of generic connection code.
The first implementation can focus on the transports needed by the related work. Existing transports can be migrated separately where useful.
Pat currently initializes and stores stateful modem transports directly on
App. Listening and outbound connections obtain these modems through transport-specific accessors such asVARAHF()andVARAFM(), while initialization, health checks, reuse, CAT/VFO handling, and cleanup are spread acrossApp,Connect, andListenerHub.This becomes increasingly difficult to manage as additional modem implementations and orchestration mechanisms are added:
pactor://transport, with its own initialization, reuse, listener integration, and cleanup.ListenerHubalready implements part of the desired pattern for listener mode. It manages transport listeners by name, initializes them throughTransportListener, retries failed listeners, tracks active listeners, and closes them centrally. VARA HF and FM listeners participate in this model through the existingVARAHF()andVARAFM()accessors.However,
ListenerHubis intentionally focused on listener accept loops. It does not manage the lifecycle or ownership of the underlying modem instances, particularly when the same modem is shared between listener mode and outbound connections. A complementary modem lifecycle abstraction would preserveListenerHub's current responsibility while providing consistent initialization, reuse, acquisition, and cleanup beneath both listening and dialing.PR #542 demonstrates why lifecycle ownership needs to be explicit. A modem may be shared by an active listener and an outbound connection, but the current proposal tracks Varanny sessions by transport scheme and performs cleanup directly in
Connect. This allows one user of a modem to stop resources still needed by another and requires transport-specific cleanup at numerous return paths.Introduce a lifecycle abstraction, tentatively called
ModemHub, for stateful modem transports.Relationship to ListenerHub
ListenerHubshould remain responsible for:The modem lifecycle abstraction should complement
ListenerHubby managing the underlying stateful resources used by listeners and outbound connections:Listeners would acquire their modem through the same lifecycle abstraction as outbound connections, while
ListenerHubwould continue managing the resultingnet.Listenerand accept loop.Responsibilities
The modem lifecycle abstraction should:
The first implementation can focus on the transports needed by the related work. Existing transports can be migrated separately where useful.