[aprssig] of interest to IGate client authors?

[Jim Alles]

​​
Thanks to each of you that helped me get this far...

I may have found something that pertains to the 'race condition' that some
operators have perceived, in relation to RX only IGates.

This test, from http://www.aprs-is.net/IGateDetails.aspx:
"the receiving station has not been heard via the Internet within a
predefined time period."
seems to have lost it's context.

It originally was found in
http://www.aprs-is.net/downloads/javaprssrvr/IGateUsersGuide.pdf as:
Section 1 - Introduction

APRS IGate was written to provide the amateur radio APRS community a
simple, but effective IGate. It does not have a GUI as it is an adjunct to
javAPRSSrvr. It does, however, provide most features desired in an APRS
IGate:


   -

   Gate messages to stations on RF based on the receiving station's
   distance computed by number of digipeater hops.
   -

   Prevent gating messages to RF if the "from" station has been heard
   directly (not via an IGate) on RF or the "to" station has been heard
   directly on APRS-IS (also not via an IGate).


It appears to me that if the former rule above is applied literally and too
broadly, then only the first IGate hearing the destination station has a
chance of transmitting. And of, course if the closest IGate is RX-only, the
message wouldn't get transmitted by any client that incorrectly applies
this test. Closest, though, not meaning distance, but the number of RF hops
and/or number of Internet router hops. Of course, the issue is latency, not
speed and this is all rather random, not something to base decisions on and
expect to get reliable messaging.

My own understanding now is that ALL IGates that have heard a station will
get messages destined for that station, along with packets from that heard
station, all "heard via the Internet" at about the same time. That alone is
not reason to deny transmission. ALL IGates may transmit that message to
RF, and should if the destination station is determined to be local by the
IGate client.

With this one specific exception:

If I read the original intent from the *IGate User Guide* properly, this
test was used to minimize RF transmission to an IGate that is beaconing on
RF, was heard by another IGate in earshot (hops or not), and has an
incoming message. There is no need for the other IGate to transmit it,
because the destination station will get the message from the Internet just
fine.

Another operational concern is interpretation of whether it just the
callsign or the CALL+SSID that is used in the test at the IGate client,
since we now have mobile devices that are only heard on the Internet, while
the same operator may be running a transceiver with a different SSID. They
should both get each others message, regardless that the Internet connected
device is not RF.

I cannot tell if the change in language was intentional. I certainly have
no idea how it has been implemented in all the various client software
packages. I have gotten clarification from Pete Loveall how it should work
in a recent conversation, without realizing it at first - thanks for taking
the time!.

Therefore, I would re-word this:
An exclusion from transmitting to RF should only be applied to message
destination stations (generally IGates) that have been 'heard' with the
specific SSID via a direct TCP-IP connection to the APRS-IS, with no
evidence of an RF PATH involved.

If a message is destined for a Internet-only client, and an RF station with
the same callsign is heard elsewhere, the RF remote should also get a copy
of the message, due to the common callsign.

Thanks for your attention to this, and forgive me if I am reading too much
into it! It is just one of those areas that I think would benefit from
being a lot more specific with the language being used.

73,
Jim A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161126/48a2f8a8/attachment.html>