[aprssig] IGATE message routing bug?
Kenneth Finnegan
kennethfinnegan2007 at gmail.com
Sun Nov 20 14:17:35 EST 2016
On Sun, Nov 20, 2016 at 6:13 AM, Jim Alles <kb3tbx at gmail.com> wrote:
> but, I am not certain about this not being able to get messages into a
> service that lives on APRS-IS:
> "a few of us noticed that we were not getting ANY messages into or out of
> the ANSRVR or CQSRVR."
>
When Bob says into or out of, he means out of. I think with the one
exception of Direwolf, I-gates unconditionally send EVERY packet they hear
to the APRS-IS, so the only way they weren't getting messages to CQSRVR was
if they were out of range of any I-gates, and no level of hand wringing
about APRS-IS filtering is going to fix that.
The I-gate filter was added to Direwolf to support the satellite guys not
getting vanity credit on aprs.fi for bouncing through a satellite if they
happened to be near an I-gate. A feature I refuse to add to Aprx because I
think filtering things going to APRS-IS will cause lots of subtle,
confusing problems.
> Not the entire RF-gate decision process, my IGate still doesn't know if
> the station is present on APRS-IS, elsewhere. (And I am worried about
> mobile smartphone clients on this point, as it is).
>
To quote aprs-is.net:
> A station is said to be heard via the Internet if packets from the station
> contain
> TCPIP* [...] in the header or if gated (3 rd party) packets are seen on RF
> gated by the station and containing TCPIP [...] in the 3 rd party header
> (in
> other words, the station is seen on RF as being an IGate).
Your station can get a very good idea of if a station is connected to
APRS-IS somewhere else, but now it seems like you're talking about saving
RF bandwidth, which isn't one of the problems you list below.
>
> The client software absolutely has to drop the packets with TCPIP in the
> path,
>
So you won't give RF-gate service to sources of messages which are directly
connected to the APRS-IS? Like CQSRVR?
>
>
> how about
> resource
> loading on a raspberry Pi client? or a radio? or
> the
> Dick-Tracy wristwatch
> that I get for some future Christmas?
>
>
Some of the APRS-IS servers are raspberry Pis. We're talking about APRS
here, which is a comically small amount of data compared to any other
modern network.
> Existing problems:
> 1. Bob not getting INTO ANSVR.
>
He was, or he was out of range of any I-gates.
> 2. The guy with the satellite link.
>
Frankly, the guy with the satellite link who can't afford a few extra
packets coming in on the 14580 port shouldn't be running an I-gate. We
shouldn't be redesigning I-gate behavior just to try and save a few guys a
couple MB per month.
> 3. Not having access to the configuration parameters, when they are
> hard-coded.
>
The last thing we need to be doing is exposing more knobs for users to turn
when setting up their first I-gate. We keep slapping on these extra
parameters to be tuned, and then I start getting bug reports against my
software because someone turned one of the knobs that they don't understand
and APRS starts doing something really whacky.
> 4. getting my IGate client instance to work the way I want it to, within
> reason and to support the entire community.
>
That is not a problem. That is a desire. What is your I-gate doing or not
doing that you want it to? When your I-gate gates "X", then receives "Y"
from APRS-IS, what does it do? What should it do?
--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161120/c81488fe/attachment.html>
More information about the aprssig
mailing list