<div dir="ltr">On Sat, Nov 19, 2016 at 10:43 PM, Jim Alles <span dir="ltr"><<a href="mailto:kb3tbx@gmail.com" target="_blank">kb3tbx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-">On Sat, Nov 19, 2016 at 11:32 PM, Lynn W. Deffenbaugh (Mr) </span><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">But I don't understand just what you think that "fixes"?<br></span></div></blockquote><div><br></div><div><div style="font-family:georgia,serif;display:inline">​Bob's original problem - message packets got dropped until after a position report was received.​</div> <div style="font-family:georgia,serif;display:inline">​Somebody configured something with the limited tools they had., to get control of the useless packets that wanted to be transmitted.​</div></div></div></div></div></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">​2. Reduce server resource loading​. See (I can't find the reference).</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">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)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div class="gmail_signature">--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<br><div class="gmail_quote"><br></div></div></div>