[aprssig] IGate Registering for ANSRVR (Messaging failures)

[Steve Dimse]

> On Jul 15, 2016, at 2:15 PM, Pete Loveall AE5PL Lists via aprssig <aprssig at tapr.org> wrote:
> 
> #1 is Anthony's example.  The RO IGate gates his HT's message packet (let's say it is a messaging capable HT) but a bidirectional packet does not because it never gets digipeated.  The remote station sees his packet but the remote station's ack and possible responses are not seen since no bidirectional IGate considers his HT as local.
> 
This is less broken than if the RO gate is not there? With an RO gate the the remote station gets the message but the HT does not get the ACK. Without the RO the remote station does not get the message. You aren't actually saying it is better the remote station does not get the message, are you? 

> #2 is a little more obscure but just as important since it is much harder to isolate.  Bidirectional IGate (let's call it RW) is connected to a server (connection type is irrelevant for this connection). That server (let's call it RW's server since it is often times either integral or in the same location as the RW IGate) is connected to APRS-IS via a restricted feed ("filter" is an inaccurate word; the feed is "restricted" to packets for the connected station and any stations the connected station has recently gated to APRS-IS plus any packets defined in a filter if defined).  Before you say it can't be or that is bad design, that is how most home installations of javAPRSSrvr are configured as they are on restricted bandwidth connections.  There are others who also run in this type of configuration.  Now, let's use the example in #1 but say the RW IGate does see that packet after one hop.  But the RO IGate already got the packet through APRS-IS to RW's server so dupe elimination prevents RW's server from sending the RW-received packet upstream.  Therefore, the upstream server to RW never sees the packet that RW gated to its server.

I want to be sure I understand this. RO and RW hear the same packet, and are connected to the same javAPRSSrvr hub. RO gets the packet to the hub first. So of course everything upstream of that server only sees the packet from RO. The payload is identical but the path shows it came from RO, and not RW. And now what? Who cares what the path says upstream? Everything upstream is not filtered or restricted. Or is the mentioned upstream not the issue, and the problem happens in the first javAPRSSrvr? Does your software do the dup filtering BEFORE it determines which IGate sent a packet and blesses the sending callsign for passing through your 'restriction'? Only one IGate connection per javAPRSSrvr is fed the messages? If it is this, it sounds like a bug. If 10 IGates are connected to a single javAPRSSrvr and all heard the same station, all should get the every message to that station, right? If it is something else please try to explain again.

The original APRServ hub offered a way to decrease bandwidth load on pure IGates by providing a feed with just messages and associated positions, and that is certain not to create problems. Granted there is more traffic now, but home bandwidth has also risen, and there aren't that many messages that it would be a serious issue for the vast majority of people. 

> 
> Now you might claim close-coupling of the software in #2 could force RW's server to send the packet anyway regardless of dupes but that is a bit self-defeating for other reasons and does not resolve the issue when the IGate is completely separate software from the server. 

Not suggesting this at all.
> 
> I am not assigning "fault" to anyone or anything.  I am pointing out how RO IGates can and do interfere with APRS messaging.  I am also pointing out how this can be very difficult to track down with the denial of such cases (and these are only 2 examples).

I'm interested in fault only to the extent it indicates what part of the system needs to change. I gave you five good reasons for one-way IGates, not to mention they are widespread and since the inception of the APRS IS they have been part of the landscape. If they really are causing a problem now the question is why and what should be done about it.

If there are more examples I want to hear them. It makes no sense that an RO IGate should interfere with two way messaging, other than discouraging new, full IGates (just as your suggestion to create a zero hop IGate does). If there really are problems, it seems to me the problems might be caused by these things you've added, like the IGate restrictions, or perhaps bugs in your code. In this case isn't the correct thing to fix javAPRSSrvr rather than try to eliminate one way IGates? 

Steve K4HG