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

[Andrew P.]

Heikki,

YAAC is theoretically capable of being an I-gate, but I don't know how many people (besides W3ATE) are using it as a bidirectional I-gate. Furthermore, it is entirely possible I have a bug in the I-gating section of the code; I know I've tweaked the APRS-IS connector code at least twice since YAAC's original beta release at the 2012 DCC.

Making sure I implemented I-gating correctly is why I started this thread in the first place. :-) Especially since I have users who want to know how to configure YAAC as an RX-only I-gate that doesn't even receive any packets back from the Internet (to save bandwidth on low-capacity wireless [cellular] Internet connections). And I don't allow that kind of configuration because:

a) I assumed that would be against the network design, and

b) I didn't know of any way to tell an APRS-IS server to not send any packets back to me (and, from what Pete is saying, that appears to be deliberately impossible).

So, hopefully that clarifies why I started this.

Andrew Pavlin, KA2DDO
author of YAAC, trying to get build 28 finished so I can release it.

------Original Message------
From: Heikki Hannikainen
To: aprssig at tapr.org
Sent: Dec 2, 2013 1:51 PM
Subject: Re: [aprssig] are write-only APRS-IS clients valid?


On Mon, Dec 2, 2013 at 8:25 PM, Pete Loveall AE5PL Lists
<hamlists at ametx.com> wrote:
>> -----Original Message-----
>> From: Heikki Hannikainen
>> 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.
>
> But that is where it breaks down which is what I have been saying all along: if the IGate client is integral within a server or if the IGate operator is running their IGate into a local server (local as in private access in their house, for instance) and that server is connected to a limited feed upstream (as it often is), a RX-only IGate can break messaging.

Yup, that seems right, especially if that limited feed upstream has a
manually set filter string instead of the default "empty filter" of a
normal 14580 port. javaprssrvr is probably the only integral igate +
aprs-is server package. Ah, aprsd is too, but it seems to be slowly
dying out in favor of aprs4r, aprx, and friends.

I'm not quite convinced that is a very common setup. In-house local
servers are relatively rare - you probably have one, I don't, and most
people just set up the simplest thing that works for an igate. And, in
this case, the simpler thing won't be affected by this issue.

Here's another statistic (high error margin as usual, but I've tried
my best), most popular igate-like software instances on the APRS-IS
for the past 30 days, according to number of callsigns appearing in Q
construct in a way that suggests igating:

http://pastebin.com/NjKUTXjr

Some software and hardware which is not capable of igating is listed,
since the most recent position packet with device identification
(tocall) has been transmitted by an Opentracker (for example), but
there's igate software connected to its serial port. Duplicate
filtering in the presence of lower-latency igates will mute some
igates down quite a bit, but even then, a single packet should
probably pass through any operating igate in 30 days.

(Where is YAAC? I thought it was an igate by now?)

- Hessu
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig


Sent from my Verizon Wireless BlackBerry