Order Tray | Contact Us | Home | SIG Lists

[aprssig] Throttleing EchoLink Objects

Alex Carver kf4lvz at yahoo.com
Thu Jul 23 04:17:34 UTC 2009

Assuming the overload on the APRS-IS is high why not cut the IS out of the equation for the IGATES?

The suggestion was floated to have another client running at the IGATE site.  Ok, skip the IS and have that secondary client directly collect the XML file from the EchoLink server and parse it locally.  No APRS-IS required at all.  The location would be programmed into this client so it could sort through the XML file on its own looking for the nearby EchoLink nodes that are nearby and up (and open since most nodes are not).

The IGATE operator wouldn't have to do anything more than allow data from the local computer pass traffic onto RF right on the spot, we still have the live data from the EchoLink server, and we don't bog down the rest of the network.

Now, this would consume a lot of the EchoLink server bandwidth depending on the frequency of downloading the XML file so we'll call the above Plan A.  Then perhaps a Plan A Section 2 would involve code running directly on the EchoLink server that could create filtered ports on its own.  An IGATE would connect to the filtered port, put in the location filter and the server would send only data that was near the location.  That would put a CPU load on the server but it would minimize the bandwidth used.  Essentially a baby version of the APRS-IS.  The IGATE would run a client program (or add a second connection) and allow traffic from the EchoLink server to pass to the RF side.



More information about the aprssig mailing list