[aprssig] APRS-IS Connection Restrictions

[AE5PL Lists]

The latest revision of the q algorithm enforces a necessary network
restriction on APRS-IS: all verified logins must be unique.  The APRS-IS
data stream has no built-in packet identification.  With such a
protocol, certain precautions are taken to ensure that looped packets
don't occur.  One of these precautions is dupe checking.  Even with 30
second dupe check queues, we have seen loops occur which have longer
than 30 second delays.

The q construct identifies point of origin, among other things.  A loop
packet is a packet that appears at any point in the network more than
once and from different connections.  The q algorithm checks the q
construct's point of origin, checks it against verified logins, and
discards the packet as a loop if the point of origin is equal to a
verified login on the server, and that login is not the login of the
connection the packet arrived via.  More info is at
http://www.aprs-is.net/q.htm

There is another reason why verified logins need to be unique among
clients: messaging.  If two clients have the same verified login and a
message is sent to that login, then two clients will respond with acks.
It gets really ugly when this is going on between RF and APRS-IS.
Because there is more than one way to ack a message, the acks may not
get duped.  And if one client rejects the message, ...  Because APRS-IS
interconnects RF networks world-wide, it falls under the same
restrictions which are found on RF networks: no two stations should use
the same callsign-SSID.  An IGate or client connected to both RF and
APRS-IS carry only one callsign and this is factored in with some IGate
software.  Any non-verified (read-only) clients may use the same login
as they do not have messaging capability (javAPRS does not require a
unique login as it uses a read-only login).

There are some clients and servers currently configured with multiple
verified connections into APRS-IS.  There are also some people who have
multiple clients configured with the same callsign-SSID combination.
These systems risk the loss of data at the core.  If you want to see how
you might be affected, take a look at http://www.findu.com/stream  Look
at the callsign after the q construct to determine if your packets are
being considered loops.  Just because your packet shows up here does not
mean it is a loop.  However, if you see multiple packets with your
callsign-SSID after the q construct being dropped by one server or
another, then you can probably assume that it is because of a perceived
loop.

Also, if you are running multiple verified connections but your packets
are not showing up as being dropped, it only means that all of the
servers are dropping those packets as looped packets, not dupe packets.
This could cause packets from your server/client to be dropped as long
as you maintain that configuration.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net