[aprssig] Periodic Disconnects from APRS-IS

[Scott Miller]

Last time I looked at a TCP dump of an APRS-IS connection, it seemed to be
making rather inefficient use of the bandwidth.  I saw exactly one line per
packet.  For slow ports (message only, local filters) this is fine - it
keeps the stream from getting held up in the TCP buffers.  But for a full
feed, it seems like you'd be better off offering a port that'd send a
maximal length packet to reduce overhead.  Should reduce the packet count by
about a factor of 10.

I don't know about Java's socket support, but I think in C it was a pretty
simple configuration option.  Again, it's not what you want for everything,
but it seems like an easy way to save bandwidth.

Scott
N1VG

> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of AE5PL Lists
> Sent: Thursday, January 18, 2007 4:05 AM
> To: TAPR APRS Mailing List
> Subject: [aprssig] Periodic Disconnects from APRS-IS
> 
> Are you having an issue where you get disconnected from an APRS-IS
> server periodically (sometimes as often as every minute)?  Are you
> connecting to a full feed (port 23, 10151, 10152 on the 
> core)?  Time to
> update your server list and start connecting to a filtered 
> port (14580 -
> user defined, others may exist that are predefined, visit the 
> web status
> page of the server you are connecting to for more information on
> available ports http://aprsserver:14501).
> 
> I just did a scan of the core server status pages and found over 10
> clients with 5 to 15 seconds of packets backed up scheduled 
> to go to the
> client.  This is caused by the client not being able to handle the
> packet flow from the server.  At 15 seconds of queued transmissions,
> your client will be disconnected to prevent loops.  Most of the time,
> this inability to handle the packet flow from the server is caused by
> the client software not being able to keep up.
> 
> However, this could also be caused by a bottleneck enroute to or from
> your client (remember that your client is generating an ack for every
> packet if it has properly shut off the Nagel algorithm).  It may seem
> like you have plenty of bandwidth, but the full feed _averages_ 25-30
> packets per second which is significant for residential broadband and
> very significant for dial-up.  It is also very significant for most
> mapping clients to keep up with processing each station report.
> 
> If you are accessing a full feed from an APRS-IS server and having
> problems staying connected, re-evaluate your need to connect to a full
> feed.  Most people have found that connecting to a filtered feed makes
> their PC and client much more responsive yet you still get full
> messaging capabilities even if your client is an IGate.  If you have a
> question about what kind of filters are available, check out
> http://www.aprs-is.net/javaprssrvr/javaprsfilter.htm
> 
> This is an informational post and in no way is meant to 
> impugn anyone's
> operation or configuration.
> 
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl.net
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
>