[aprssig] aprsD Multiple Connects

[Pete Loveall AE5PL Lists]

I have noticed a resurgence in aprsD configurations that have multiple outbound connections (simultaneous connections to different upstream servers).  While I am sure the sysops feel they have some justification for this, these sysops do not realize that they are degrading the service to their users and placing an unnecessary excess load on the upstream servers.

First, an explanation of why this can and does degrade service to the users.  When aprsD makes a read-only hub connection, it uses a verified login (a login that says "I am authorized to send and receive").  This means that if the upstream server is javAPRSSrvr, no packets seen entering APRS-IS from the aprsD server will be passed.  This is because javAPRSSrvr -must- make the assumption that the packets received from elsewhere but shown as entering APRS-IS from the verified login "client" is a looped packet.  For instance, there is currently an aprsD server connected to first.aprs.net with a read-only connection and to second.aprs.net with a bidirectional connection.  All packets entering APRS-IS via that aprsD server will -not- be seen by any clients connected to first.aprs.net or any server connected to first.aprs.net.  This loop protection is necessary and has been in place for a number of years.

Second, this same aprsD server is connected to port 14580 of first and second.aprs.net.  This needlessly takes a connection away from other potential users without any benefit to the aprsD users.  Why?  Because aprsD does not support sending filter commands to the upstream server and port 14580 is a user filter port.  This will allow messaging to a degree via second (remember, no one connected via first will ever see packets from this aprsD server or its connected clients) but dupe checking might eliminate reliable messaging as well (this aprsD server is also connected to 4 other servers with bidirectional connections).

So what we have is something that dates back to the instability prevalent in 2000-2002 in APRS-IS where servers were up and down like yo-yos.  The "work-around" was for software authors to permit multiple upstream connections so no packets would be lost if a connection disappeared.  Unfortunately, that "work-around" also introduced more issues causing more server crashes by creating looping conditions, overloaded servers, etc.  Today there is zero justification for multiple simultaneous connections to APRS-IS servers.  As shown, multiple simultaneous connections are actually a detriment to the offending server's clients as well as monopolizing connections that would otherwise be used by other APRS servers and clients.

If you use multiple simultaneous connections to connect to APRS-IS, please reconsider based on your impact on your users and on the upstream servers.  This is also why -all- callsign-SSIDs -must- be unique if they may appear on APRS-IS (loop & dupe checking).  Could some of this be overcome with a new APRS-IS protocol?  Yes.  Is a new protocol practical?  Not with the vast majority of clients being software written around the current protocol and not likely to change (UI-View, APRS+SA, aprsD, and WinAPRS are no longer in development, to name a few).

73,

Pete Loveall AE5PL
pete at ae5pl dot net