[aprssig] are write-only APRS-IS clients valid?

[Pete Loveall AE5PL Lists]

Actually, a better way to think of it is that a server is configured such that all clients are considered bidirectional IGates.  Lynn is correct in stating that the server does not differentiate between IGates and other clients.  As he stated and has been stated throughout this thread, the server maintains a separate "recently heard" list for each validated client on a limited feed and passes message packets addressed to any station on that "recently heard" list to the client (the client is always considered to be on that list).  The server will also pass the next valid posit from the message originator to the client so it can be sent out "as a courtesy".  Finally, if any packets are seen originating from a station on the "recently heard" list that were directly injected into APRS-IS (TCPIP* is the only "digipeater" in the path), those packets are sent to the client.  If a client is not an IGate, its "recently heard" list is empty but the above processing is still performed (of course netting no packets beyond messages and associated posits addressed to the client).

It is important that the server makes no decisions for the client regarding what packets are going to be sent to the client.  It is 100% per the above algorithm so if the client is an IGate, it gets sufficient information to perform its IGate function.  As also stated earlier, the "filters" (better term "subscriptions") that a client can set are additive to the above algorithm but do not override it.  Finally, full feed ports do not implement the above algorithm since all packets the server sees are passed to the client anyway.  This algorithm only exists for limited feed ports.

The server's job is to pass packets to all clients as quickly and efficiently as possible while eliminating duplicates and preventing loops and mangled packets.  When a client connects to a limited feed port, the server restricts the packets passed to the client to the above algorithm (the client is always considered "recently heard") and any filters that might also be defined, if any.  This assumes, of course, that the client has provided a valid passcode at login.

It is the responsibility of the client software to function as an IGate per the spec if it is an IGate and it is the responsibility of the server to make sure that all packets as defined in the above algorithm are always passed to the client.

Don't put too much "intelligence" into how a server operates.  They are designed to move volumes of packets to all clients without regard to what a particular client is.  That design includes ensuring that limited feed ports pass the minimum packets necessary to fully support messaging to the client and for any clients located behind the directly connected client (i.e., an IGate).  That design is port and connection related, not client related (again, the server does not know what function a client might perform).

Hope this helps.  

73,

Pete Loveall AE5PL
pete at ae5pl dot net


> -----Original Message-----
> From: Lee Bengston
> Sent: Tuesday, December 03, 2013 6:05 PM
> 
> But what delivers a packet for a "given source" other that itself if it is not an
> IGate?  Hmm perhaps sending an object applies there.  The reason I implied
> recognizing an IGate is that in my little experiment 2 years ago, I configured
> Xastir with no filter and normal beaconing on both RF and IS.  I got nothing
> from the IS in terms of APRS packets.  As soon as I enabled Igating in Xastir, I
> received the packets we have been discussing, so effectively the application
> was "recognized" as an IGate.  Perhaps it is better to say it is recognized as
> something that might be an IGate.