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

Andrew P. andrewemt at hotmail.com
Sun Dec 1 22:35:29 EST 2013


Greetings, all.

I've had what seems to be an odd request for a feature expansion to my APRS client YAAC, and I want to make sure it's sane before I implement it.

I've had more than one user ask how to configure my client to be a write-only client to APRS-IS, that is, relaying RF-received packets to APRS-IS, but refusing to accept any traffic back for possible relay back to RF. I've seen a lot of receive-only IGates on the map, but how does one tell the APRS-IS servers that a given Igate does not accept traffic for relay to RF? Having a write-only GUI client seems to be a little strange (as in, why not use aprx or some similar daemon-style client instead of a GUI client like YAAC?).

I could implement this in one of three ways:

1. configurably dump all APRS-IS sourced incoming APRS messages on the floor instead of processing them.

2. continue to receive incoming APRS-IS packets normally, but configurably flag that they should not be forwarded to any RF ports for transmission. (YAAC has existing filter logic so that received APRS-IS packets could be hidden from the GUI while still being processed in the background, intended for selective data analysis.)

3. somehow tell the APRS-IS server in the login request that I don't want to receive any APRS packets at all (how would I do that?).

Any answers, folks? Especially, I'd like to hear from Pete Loveall AE5PL, since he is the person more or less in charge of the APRS-IS backbone (as much as anyone is).

Thanks in advance.

Andrew Pavlin, KA2DDO
author of YAAC ("Yet Another APRS Client")
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131201/c481f418/attachment.html>


More information about the aprssig mailing list