<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">comments to Kenneth in-line:</div><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 dir="ltr"><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"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><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></span></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. <div class="gmail_default" style="font-family:georgia,serif;display:inline"></div>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></blockquote><div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">but, I am not certain about this not being able to get messages into a service that lives on APRS-IS:</div><div class="gmail_default" style="font-family:georgia,serif"><span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:14.6667px">"a few of us noticed that we were not getting ANY messages into or out of the ANSRVR or CQSRVR."</span><br></div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div><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"><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)</div></div></blockquote><div><div class="gmail_default" style="font-family:georgia,serif">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).</div></div><div> </div><div><div class="gmail_default" style="font-family:georgia,serif">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. </div></div><div> </div><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"><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></blockquote><div><div class="gmail_default" style="font-family:georgia,serif"></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Yes, I am aware, that is what motivated me to engage with yinz here. I discovered that variability while testing.<br></div><br></div><div class="gmail_default" style="font-family:georgia,serif">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'. <div class="gmail_default" style="display:inline">I haven't even been able to find configuration parameters for the</div><span style="font-family:arial,sans-serif"> 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.</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif">Shouldn't I be able to configure how many related position beacons to transmit? In my</span><span style="font-family:arial,sans-serif"> </span><span style="font-family:arial,sans-serif">hi-load</span><span style="font-family:arial,sans-serif"> 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.</span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif"><br></span></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif">Others might want them all. A special event might want something in-between on RF. Let the local operator decide.</span></div><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"><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? </div></div></blockquote><div><span style="font-family:georgia,serif"></span><br></div><div><div><div class="gmail_default" style="font-family:georgia,serif">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.</div></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif"> </span><br></div></div><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"><div class="gmail_extra">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></blockquote><div> </div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">Whoa - IGate client software - yes. IGate instances NO.</div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline"></div><span style="font-family:georgia,serif">how about<div class="gmail_default" style="font-family:georgia,serif;display:inline"> resource</div> loading on a raspberry Pi client? or a radio? or <div class="gmail_default" style="font-family:georgia,serif;display:inline">the</div> Dick-Tracy wristwatch<div class="gmail_default" style="font-family:georgia,serif;display:inline"> that I get for some future Christmas?</div></span> </div><div class="gmail_default" style="font-family:georgia,serif"></div><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-"><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></span><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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">Not my concern. To quote the <a href="http://www.aprs-is.net/downloads/javaprssrvr/Overview.pdf">overview.pdf document:</a></div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">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.<br></div></div><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif"><br></div></div><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"><div class="gmail_extra"></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></blockquote><div> </div><div><div class="gmail_default" style="font-family:georgia,serif">I knew I shouldn't have mentioned NOHERD ;-)</div></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">I wish we had more details on Bob's operating environment when he noticed the issue.</div><div><br></div><div class="gmail_default" style="font-family:georgia,serif">Existing problems:</div><div><div class="gmail_default" style="font-family:georgia,serif">1. Bob not getting INTO ANSVR.</div><div class="gmail_default" style="font-family:georgia,serif">2. The guy with the satellite link.</div><div class="gmail_default" style="font-family:georgia,serif">3. Not having access to the configuration parameters, when they are hard-coded.</div><div class="gmail_default" style="font-family:georgia,serif">4. getting my IGate client instance to work the way I want it to, within reason and to support the entire community.</div><br></div><div class="gmail_default" style="font-family:georgia,serif">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.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">My first step is not to describe how to do it, but allow for the possibility in the design document.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Thanks for being there, everyone!</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Jim A.</div></div></div></div>