The singleton's max_delta was being modified by test_init_custom_stale_timeout
and not restored, causing test_is_stale_connection_false to fail because
it expected 2 minutes but got 60 seconds.
The APRSISDriver uses @singleton decorator which transforms the class
into a function. The test was incorrectly trying to use __new__ which
doesn't work with decorated singletons. Instead, re-initialize the
existing instance after changing the config.
Add a new 'stale_timeout' configuration option to the aprs_network config
group that allows users to customize how long to wait before considering
an APRS-IS connection stale.
Problem:
The stale connection threshold was hardcoded to 2 minutes. In environments
with frequent network hiccups or when using certain APRS-IS servers that
may drop connections silently, 2 minutes can be too long to wait before
reconnecting, resulting in significant data loss.
Solution:
- Add 'stale_timeout' option to aprsd/conf/client.py with default of 120s
- Update APRSISDriver.__init__ to use the config value
- Maintain backward compatibility by defaulting to 120s if not configured
- Update tests to handle the new configuration option
Usage:
[aprs_network]
stale_timeout = 60 # Reconnect after 60 seconds without data
The default remains 120 seconds (2 minutes) for backward compatibility.
The client registry defined a protocol that all drivers had
to implement. This patch ensures that all methods are
consistent in the protocol definition.
It's been confusing for a while that when we configured aprsd,
we had to enter the callsign in the [DEFAULT] section and
the [aprs_network] section.
This patch removes the login from the aprs_network section. aprsd
will now use the main callsign in the [DEFAULT] section as the callsign
to login to the aprsis network.
This patch includes a completely reworked client structure.
There is now only 1 client object, that loads the appropriate
drivers. The drivers are fake, aprsis and tcpkiss.
The TCPKISS client was written from scratch to avoid using asyncio.
Asyncion is nothing but a pain in the ass.
If any part of the code had a packet object and called prepare()
on it, it would create a msgNo if it wasn't set. Sometimes we
get packets on the wire/RF that don't have a msgNo, so adding one
locally is wrong. We should ONLY create a msgNo on a packet that
is destined for transmission.
This patch ensures that even if prepare() is called, that only
packets that are created locally for TX get a msgNo unless it
already exists from RX'd packets.
