[aprssig] IGate (Identification? (RO or RT)?
spam8mybrain at yahoo.com
Sat Jul 16 07:39:47 CDT 2016
Well, if they wanted to play nice, the Rx-only I-gates could use your defined overlay code of R, so their symbol indicates that they're receive-only. Of course, they would have to beacon to the APRS-IS; stealth I-gates would still not be seen except indirectly by their forwarding callsign.
-------- Original message --------
From: Robert Bruninga via aprssig <aprssig at tapr.org>
Date: 07/16/2016 12:01 AM (GMT-05:00)
To: TAPR APRS Mailing List <aprssig at tapr.org>
Subject: [aprssig] IGate (Identification? (RO or RT)?
Is there a way to see who is one way, and who is 2 way?
I dont think so.
Looking at the raw packets, I see 6 IGates that hear my 2-2 packets (yes, I coiuld drop to 1 hop), but if the local 1 hop IGaqtes are 1 way only, then I just shot byself in the foot and dont know it.
So now the question is, can we ADD IT somehow.
It would have to be ADDITIVE. That is, once we come up with the bit (we only need ONE bit somewhere in the QXX construct to indicate it). Then we can at least see all future 2-way IGates (assuming all existing code is 1 way utnil upgraded). Is there a way to do this without breaking anything?
That way I can see on a map WHERE my nearest 2 way gate is when traveling and know what I am facing when traveling.
I think UIVIEW had a flag about being 2 way? Others?
On Fri, Jul 15, 2016 at 5:52 PM, Steve Dimse via aprssig <aprssig at tapr.org> wrote:
> 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?
aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig