[aprssig] Periodic Disconnects from APRS-IS

[AE5PL Lists]

This is not an issue of computer buffering but of TCP buffering.  We
found the Nagel algorithm to be severely harmful to the APRS type of
traffic as was born out by the substantial delays (seconds, not
milliseconds) that were seen a few years ago before we disabled it.
Again, this is not an issue of programming technique or trying to
optimize an unknown TCP stack (yes, every OS implements the stack
differently), it is an issue of passing a near-real-time protocol
without delays which can induce loops, among other issues.  This has
been explored from many angle and eliminating buffering was the only
solution to keep APRS-IS stable and representative of the information it
is carrying.  Once again, the bandwidth involved is minimal and a
_non-issue_.

APRS software authors, PLEASE DO NOT use buffering on your APRS-IS TCP
sockets (set the socket to TCP_NODELAY).  All buffering has caused in
the past is problems because the APRS protocol is meant for immediate
(not delayed) delivery.  Assuming that the minimum buffering time is the
maximum buffering time is not understanding how the Nagel algorithm
works and I recommend you review the extensive studies on this subject
that have been done on protocols similar to APRS.

73,

Pete Loveall AE5PL
pete at ae5pl.net

> -----Original Message-----
> From: Scott Miller
> Posted At: Thursday, January 18, 2007 8:52 PM
> Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
> 
> That's why I suggested it'd be useful on high-volume ports.  If you're
> carrying the full IS feed, you're looking at maybe 100 msec of
> buffering
> time.  If it can be supported by the server software, why not reserve
a
> buffered port?