[aprssig] Recommended Behavior for Read-Only APRS-IS Clients?

Pete Loveall AE5PL Lists hamlists at ametx.com
Sun Apr 19 11:18:49 CDT 2015


As I said, don't read between the lines.  I didn't say that it was "infallible".  I said that if it doesn't say something, it isn't there.  Your questions are "reading between the lines".  There is no specification on what that the interval is for server generated keep-alives because there is no APRS-IS specification.  What has become standard practice is for servers to generate the keep-alive comment line after 20 seconds of no data sent.  If you note, the statement is "most servers" as some server software did not (does not) do this normally because they do not implement any type of reduced feed port.  This keep-alive comment line became important when we introduced reduced feed ports.  20 seconds was determined a good interval because some clients at the time would consider the server as "gone away" after 30 seconds to a minute (it was the clients driving this, not the servers).

Your next questions were regarding the TCP protocol which is not addressed for clients at all except to state that disabling the Nagle algorithm is recommended because some operating systems will delay packets to see if they can make a bigger TCP packet if it is not disabled.

You need to ask the aprsc authors regarding their code.

The aprs-is.net web site does not address TCP parameters that will vary greatly between operating systems (other than disabling Nagle if you are sending packets on a bidirectional connection).  What the aprs-is.net web site does address is the things that are "mandatory" for each installation.  Authors are allowed to make their own determination for implementation of various aspects but it is a mistake to say "this software implements it this way so all do".  The aprs-is.net site is the reference site for implementing a client, IGate, or server application but it is not a specification nor is it a "how-to".  And if there are questions regarding a specific part of that site, I am always available to answer them via email off-list (I don't always monitor all of the lists that I am a member of on a daily basis).

For implementation specific questions, I recommend you contact the authors of that software when you find a possible discrepancy such as you put forth here.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Kenneth Finnegan
> Sent: Sunday, April 19, 2015 10:07 AM
> 
> > If it is not there, don't "read between the lines" thinking that it was just left
> out; it wasn't.
> 
> Well if you're going to claim that the APRS-IS spec is infallible, then let's really
> dig into it then.
> 
> The only line I see regarding keep-alive reads as follows:
> 
> > Most servers will also periodically send lines beginning with a # to check the
> connection if there has been no activity on the TCP port.
> 
> What is this time period? How long should my client wait before concluding
> an APRS-IS connection is dead and reset it? Should my client not implement
> an L5 timeout at all and only depend upon the same L4 timeout that you
> claim the server uses?
> 
> If APRS-IS clients truly should not send keep-alive packets, then how do I
> reconcile this with the existence of the "ClientTimeout"
> parameter in the aprsc configuration? A default install of aprsc sheds silent
> clients after 48 hours (regardless of their verified status, I tested this by
> changing the default "ClientTimeout 48h" to "ClientTimeout 25s"). What L5
> keep-alive is aprsc expecting? Has this been disabled on all the
> rotate.aprs.net servers? www.aprs-is.net does not say "APRS-IS servers
> must not implement L5 timeouts," so this aprsc behavior seems perfectly
> valid to me.


More information about the aprssig mailing list