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

[Pete Loveall AE5PL Lists]

My statement was accurate regarding the keep-alives described at aprs-is.net.  The keep-alives you describe were non-existent when I created javAPRSSrvr because of the continuous traffic on APRS-IS that was in place at the time.  While you may have implemented keep-alives earlier, they became necessary again after the introduction of reduced feeds to ensure clients would not disconnect.  And it was stated to me at the time that clients had those timers to ensure the server software had not just quit processing which was also common place at the time I created javAPRSSrvr.

Good to know that you also had keep-alives in prior years when activity was low to support keeping clients from disconnecting.  Again, the point was that this was client driven, not driven by server needs.

73,

Pete Loveall AE5PL
pete at ae5pl dot net



> -----Original Message-----
> From: Steve Dimse
> Sent: Monday, April 20, 2015 9:59 AM
> Subject: Re: [aprssig] Recommended Behavior for Read-Only APRS-IS
> Clients?
> 
> 
> On Apr 19, 2015, at 7:43 AM, Pete Loveall AE5PL Lists <hamlists at ametx.com>
> wrote:
> 
> > The reason for a keep-alive from the server was initially because early
> server software would sometimes get overloaded and just quit responding.
> 
> No, the keep-alive was first implemented for almost the exact opposite
> reason - too little traffic. It is almost comical to consider now, but the early
> APRS-IS was so sparsely populated that 30 second gaps without any traffic
> were common, and much longer ones were possible, especially if one of the
> two original IGates were down (and certain if both were down). PPP
> software commonly disconnected without activity in a short amount of time,
> so the keep-alive was there to keep a client connection up through both TCP
> and PPP protocols when there was nothing on the feed. The first time aprsd
> or APRSserv overloaded was years after keep alive was implemented.