[aprssig] IGATE message routing bug?

[Kenneth Finnegan]

On Sat, Nov 19, 2016 at 10:43 PM, Jim Alles <kb3tbx at gmail.com> wrote:

> On Sat, Nov 19, 2016 at 11:32 PM, Lynn W. Deffenbaugh (Mr)
>
>> But I don't understand just what you think that "fixes"?
>>
>
> ​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.

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

>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?

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

​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)

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.

--
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/57206385/attachment.html>