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

Pete Loveall AE5PL Lists hamlists at ametx.com
Sun Apr 19 07:43:42 EDT 2015


Clients do not send keep-alives and should not send keep-alives, regardless of whether they are read-only or fully bidirectional.

The reason for a keep-alive from the server was initially because early server software would sometimes get overloaded and just quit responding.  The keep-alive was to let the client know that the server was still active on that connection.  Today, it also serves as a keep-alive to the server to ensure the client is still there because the TCP protocol has its own timeout functions that says "if this packet is not acknowledged in X amount of time, the connection has been severed" (oversimplification).  It is because of this TCP timeout that a client should never send keep-alives and servers do not have timers to look for data from a client.  This is also why if you are taking a full feed via UDP the TCP connection is maintained to determine if the client goes away.  See www.aprs-is.net for more information on APRS-IS communications.  If it is not there, don't "read between the lines" thinking that it was just left out; it wasn't.

Hope this helps.

73,

Pete Loveall AE5PL
pete at ae5pl dot net

> -----Original Message-----
> From: Kenneth Finnegan
> Sent: Saturday, April 18, 2015 10:11 PM
> 
> As always, I come to you with an oddly specific question on undefined APRS
> behavior.
> 
> When someone is implementing an APRS-IS client, they would typically
> connect to server.aprs.net:14580, and send a login line containing "user
> MYCALL pass **** [filter ...]"
> 
> The APRS-IS server would then respond with a "# Welcome etc. etc." and
> start feeding the IS client any requested / implicit packets that should be sent
> to the client, and TYPICALLY send a "# I am an APRS-IS server and am alive"
> line every 20 seconds.
> 
> My question is: What is the recommended best practices when
> implementing a read-only APRS-IS client for connection keep-alive in the
> client->server direction? (A typical read-only application could be something
> like a telemetry collection daemon)
> 
> I know that the default ClientTimeout for aprsc is 48 hours, so I'd expect
> clients wouldn't need to send keep alive lines anywhere near the APRS-IS
> keep-alive frequency. I have found examples of mute clients connected to IS
> servers on the order of weeks, but that seems to depend on unusually
> forgiving behavior by the server.
> 
> My guess would be I should send a "# APRS-IS client keep-alive" line once
> every... hour? Is that acceptable behavior? Is there a strong reason why it
> should be "MYCALL>APRS:>Comment" vs the same "# Comment"
> format that the IS server uses?



More information about the aprssig mailing list