cbs228 / ardop_interface Goto Github PK

There should be some mechanism which enables the discovery of remote peers. Specifically, we should add a monitoring mode to ArdopTnc which listens for callsigns and grid squares from:

• ID frames (IDF)
• PING requests

The monitoring mode should also optionally LISTEN for incoming connections.

We should also consider whether or not to cache this information as a "heard list" and make it available to clients. But I believe that this functionality is better suited for higher-level applications.

Enable support for sending ping requests. The TNC does not send "ping timeout" notifications to the client, so we will have to put a timeout on that call ourselves.

Remove our home-grown Framer and replace it with futures_codec. This is an API-breaking change, but it is for the better.

Clients must monitor the BUSY TRUE|FALSE state of the TNC in order to avoid transmitting over other parties. These messages need to be consumed and time-tagged. Logic must be written to determine how much inactivity constitutes a clear channel.

In 0.2.0-alpha.1, it was suggested that the caller could chain timeouts onto TNC futures. This is not safe to do for connect(), as the timeout might expire after dialing has begun but before it finishes. The busy detection logic needs an internal timeout, which should be adjustable. It may be worth adding timeouts to listen() et. al. as well. These changes might be implemented in a breaking manner.

We should add a FecSocket for ARDOP's unconnected, forward error-correction mode of operation. FEC is very similar to UDP, except that packets may be repeated. FEC frames may also be co-mingled with ID frames.

The biggest hurdle is the need to specify the FECMODE. The available modulation modes change with every major release of ARDOP. We can either:

1. Tie our public API to ARDOP major versions; OR
2. Abstract the mode selection process out somewhat.

In general, (1) is the choice with the simpler implementation, and it is probably the correct one.