[aprssig] are write-only APRS-IS clients valid?

[Heikki Hannikainen]

On Mon, Dec 2, 2013 at 6:50 PM, Steve Dimse <steve at dimse.com> wrote:
> On Dec 2, 2013, at 10:46 AM, Pete Loveall AE5PL Lists <hamlists at ametx.com> wrote:
>> Your statement "Dupe elimination means eliminating dups, not eliminating messages." is incorrect because messages are packets just like any other packet and, therefore, they are subject to dupe elimination as well.  So, start with that understanding that messages are handled as any other packet in the backend of the APRS-IS server.
>
> Of course. However by definition what is being removed are the duplicates of the message, not the message itself. One copy, the first copy, gets through. However from below I see you are using filtering and not dup checking as the agent here.

I've reimplemented the algorithms in question in C in the aprsc
project. I have tested javaprssrvr's behaviour by implementing a
testing client suite which tests a lot of scenarios against both aprsc
and javaprssrvr, and Pete has answered a lot of my questions on this
subject, so aprsc's implementation should be quite compatible. There's
a messaging test in the suite which exercises just this functionality
by connecting multiple clients to the server and then passing packets
back and forth. I'll try to describe what I've learned and
implemented.

I'd assume the position (or other beacon) packets, which are
transmitted by the future recipient of the message, and which cause
entries to be inserted in the "heard list" so that messages will be
passed to the recipient, might get dropped in the dupe filter in some
situations (though I didn't quite find any really common and obvious
cases yet), and the "heard list" would not be populated, potentially
causing messages to be dropped.

> The last heard filter is not mentioned in the filter or Igate design and details pages. Where is it explained on aprs-is.org? If I missed it I’m sorry, but it is a key piece of information I either missed or that is absent from the pages. Also I did not see info that filtering is applied based on this last-heard list. From the way you describe it, dup-checking is done on the hubs before the last-heard table is updated. So it isn’t really a last-heard table, but a first-heard table of the most last packet, right?

The "heard" table is a list (well, a hashed structure for quick
lookups) of stations heard within some time (3 hours in aprsc, I think
javaprssrvr's timer is similar) by a client connected to a filtered
port. Each client socket has its own list, so the server remembers all
of the igate clients which heard a given station recently.

If the same station is heard by multiple igates connected to filtered
ports, at least the javaprssrvr 4.0 version I've last tested with (and
aprsc) will send the message to all igates, so there will likely be
multiple transmissions on RF. The test suite's test case only tests
with two igates, though.

> Does the range filter override this filtering?

The filters and the "heard list" are additive, so no, doesn't override.

If the message's recipient is in the heard list for a given client,
the message will be given that way, even if it doesn't match any
filters set by that client.

> Yes, I was assuming IGates would use a range filter specifically to be sure they would receive the messages for all stations in that area. You don’t want that, though, do you?

Most igates don't send range filters (or any other filters), since
they don't need to see all packets in the area. The "heard list" alone
should nicely give them the necessary packets for messaging to work.

Back to the scenarios:

(1) if a server A, implementing the heard list and dupe filtering, has
a full APRS-IS feed, it is guaranteed to get a copy of the message
packet no matter what. (2) If a TX igate client does not do dupe
filtering on its own, and gives all received packets sent by (future
message recipient) station S to server A, the server will have it on
the "heard" list, and give the igate all the right messages for
transmitting, even if for some reason some packets would be heard by
an RX-only igate first.

If, on the other hand, server A does *not* have a full APRS-IS feed,
and it does duplicate filtering, and it for some reason receives
station S's position beacon from its upstream first (due to it being
heard first by an RX-only igate somewhere else), it might not pass the
later copy received by the TX igate to its upstream server, causing
the upstream server to not know that the TX igate can potentially pass
on a message to S. I can't come up with a good explanation why the
upstream server would give that beacon to server A in the first place
- maybe server A gave a filter string of some sort to the upstream
server, one that does give it the rx-igated beacon packet quickly but
does not give the messages it'd get in the full feed. But that should
be quite a rare setup, I hope?

As I understand this, for messaging to work nicely in the presence of
rx-only igates:
- APRS-IS servers which implement dupe filtering and provide filtered
connections for igate clients should always be connected to a full
feed.
- iGate clients should pass all received packets to their upstream
servers and should not try to do duplicate filtering themselves.
But maybe I'm wrong, wouldn't be the first time.

- Hessu, OH7LZB