[aprssig] IGATE message routing bug?

Sun Nov 20 09:13:22 EST 2016

comments to Kenneth in-line:

>
>> Bob's original problem - message packets got dropped until after a
>> position report was received.
>>
>> Somebody configured something with the limited tools they had., to get
>> control of the useless packets that wanted to be transmitted.
>>
>
> Bob's original issue is that there is disagreement between implementations
> on the definition of what stations are "near-by" and which units (km or
> hops) should be used when expressing the concept of near-by.
> 
> When your RF-gate heuristic is "within 50km of me" you HAVE to wait for a
> position packet before starting to RF-gate to a station. If your metric is
> instead "within one digipeater hop of me" you can start providing RF-gate
> service as soon as you receive any type of packet.
>
Thank you for giving a peek into the logic for us. and yes, the 'HAVE to
wait' is the surprise Bob experienced, even though it is driven by a
provision in the design.

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."

> I don't see how you have changed anything here other than moving when the
> RF-gate decision is made. As it stands now, I-gates send all their traffic
> to 14580 and then get CCed back on all packets that the APRS-IS considers
> at all possibly relevant to that I-gate; the I-gate then processes this
> feed from the APRS-IS to decide which packets to RF-gate (which is very few
> of them)
>
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).

Instead of making a decision to drop packets before they hit my
heard-list, (I want to & can do that with Direwolf now) send them to a port
that won't load them into my heard list. That at least, saves some packets
from doom. And doesn't hold up messages until the position is determined.
The APRS-IS doesn't care where they came from.

> From what I understand, you're proposing that I-gates process their
> traffic to decide which stations they'd RF-gate for, split this traffic
> between 14580 and UDP 8080, then (unconditionally?) RF-gate anything that
> comes back from the APRS-IS on port 14580 to the local RF. Are you aware
> that the behavior from the server on 14580 isn't well enough defined that
> there is noticeable differences depending on which brand of APRS-IS server
> you connect to? What about I-gates with GUIs, which users like to see fill
> up with stations?
>

Correct, but not unconditionally. The client software absolutely has to
drop the packets with TCPIP in the path, after making the general decision
to TX a station's messages and related position beacons to RF, which is a
later decision, still.

Yes, I am aware, that is what motivated me to engage with yinz here. I
discovered that variability while testing.

And for the IGate operators that have a GUI, they should be able to
configure for whatever they want to see. maybe as a separate configuration
'filter'.
I haven't even been able to find configuration parameters for the
 RF-gate heuristic "within 50km of me" in two IGate clients I have used. As
an operator, I should always have access to that. Maybe I don't know where
to look.

Shouldn't I be able to configure how many related position beacons to
transmit? In my hi-load RF-channel territory due to (3) mountain-top
tower-mounted digis, I am only willing to TX one - maybe. I haven't tested
yet while listening with my ears.

Others might want them all. A special event might want something in-between
on RF. Let the local operator decide.

>
> The issue at hand is how the I-gate decides what to RF-gate, not when that
> decision is made (When uploading packets vs when getting packets to RF-gate
> from the APRS-IS). What algorithm would the I-gate use to split traffic
> between 8080 and 14580 other than the same one it currently uses when
> processing packets received from the APRS-IS port? What happens if someone
> connects to a 10152 port instead of a 14580 port?
>

I am willing to consider these design issues and respond separately. And
you are neglecting the guy with the satellite link. He wants nothing back.
I would like to see that flexibility.

> I-gates MUST be able to handle receiving a full feed, and many of them do.
> Receiving unexpected packets from the -IS, looking at them, and then
> dropping them is nowhere near as big of an issue as you seem to be making
> it out to be.
>

Whoa - IGate client software - yes. IGate instances NO.

how about
 resource
loading on a raspberry Pi client? or a radio? or
the
 Dick-Tracy wristwatch
 that I get for some future Christmas?

>
> 2. Reduce server resource loading. See (I can't find the reference).
>
>
> No. Under no condition should any APRS design decisions be dictated by
> dreamt up scalability concerns for the APRS-IS servers. To quote the 2012
> aprsc DCC paper: "At the nominal 50 packet/s rate CPU usage was too low to
> be measured accurately" and 100-1000Mbps server connectivity should be the
> norm for APRS-IS servers in 2016. (I figure a 100Mbps connection can handle
> about ~2000 FULL feed clients)
>

Not my concern. To quote the overview.pdf document:
<http://www.aprs-is.net/downloads/javaprssrvr/Overview.pdf>
Remote Clients Remote clients can connect to javAPRSSrvr via TCP or UDP. A
TCP connection can also support a UDP feed from javAPRSSrvr to reduce
loading on the server (no TCP overhead). UDP ports are receive-only and can
either receive from predefined IP addresses or from any remote client if
the UDP packet contains a login line in addition to the APRS packet.

In any case, we're getting lost in the weeds here. Before you start
> describing how us I-gate programmers need to be rewriting our uplink
> interfaces to the -IS and how we should be defining a new NOHERD alias to
> solve something, you need to very clearly describe an existing problem, how
> the current algorithm does not solve this problem, and how your change
> would improve on it. I still have not seen any of your comments line up a
> real existing issue with a possible solution to it.
>

I knew I shouldn't have mentioned NOHERD ;-)

I wish we had more details on Bob's operating environment when he noticed
the issue.

Existing problems:
1. Bob not getting INTO ANSVR.
2. The guy with the satellite link.
3. Not having access to the configuration parameters, when they are
hard-coded.
4. getting my IGate client instance to work the way I want it to, within
reason and to support the entire community.

I do realize that it is the desire to deal with these kinds of issues that
motivated you to re-write your own client. And that I might have to do the
same, if I can't get anyone to help.

My first step is not to describe how to do it, but allow for the
possibility in the design document.

Thanks for being there, everyone!

Jim A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161120/31a5e46a/attachment.html>