This patch adds basic ratelimiting to sending out AckPackets
and non AckPackets. This provides a basic way to prevent
aprsd from sending out packets as fast as possible, which isn't
great for a bandwidth limited network.
This patch also adds some keepalive checks to all threads in the
threadslist as well as the network client objects (apris, kiss)
The messaging.py now is nothing but a shell that
contains a link to packets.NULL_MESSAGE to help maintain
some backwards compatibility with plugins.
Packets dataclass has fully replaced messaging objects.
This patchset allow getting the GPS coordinates from the browser's
geolocation API (which can be denied by user), then send's the GPS
coordinates to aprsd via socketio and then aprsd sends a beacon.
This allows the APRS network to know the location of the person running
the webchat app via browser so packets can get routed back to it.
This patch reworks the KISS client to get rid of
aioax25 as it was too difficult to work with due to
heavy use of asyncio.
Switched to the kiss3 pypi library.
This patch changes how aprsd identifies itself when connected to
any client, which is not relying on the login for each client.
There are 3 supported clients currently
aprsis,
tcpkiss
serialkiss.
Each client has their own potential login/callsign to connect
to the remote. This patch tells aprsd to use the new config option
aprsd.callsign as a means to identify itself. It will accept
packets as <aprsd.callsign> and reply as <aprsd.callsign> regardless
of which client object is being used to connect to the remote.
Note: this breaks backwards compatibility. This patch now requires
the new config option
aprsd:
callsign: <callsign>
This patch completely refactors and simplifies how the clients
are created and used. There is no need now to have a separate
KISSRXThread. Since all the custom work for the KISS client is
encapsulated in the kiss client itself, the same RX thread and
callback mechanism works for both the APRSIS client and KISS Client
objects. There is also no need to determine which transport
(aprsis vs kiss) is being used at runtime by any of the messages
objects. The same API works for both APRSIS and KISS Client objects