[aprssig] NetNodes, the future USE FLEXNET
Brian Webster
bwebster at wirelessmapping.com
Wed Dec 29 11:12:46 EST 2004
The idea Bob has and the system Pete speaks of in Germany use Flexnet if I
recall. The nice thing about flexnet is that is can interface to the
internet fairly easily. The beauty of flexnet is it's adaptive parameters
based on network traffic. It also has smart routing and load balancing
features. If there is a failure of a path and another exists it just uses
another route automatically. Since it is a smart system, it also has
knowledge of everything it can connect to. If you can connect to a flexnet
node you merely have to give it the destination call and it will
automatically route the packets to that location based on the best path(s)
it knows of. If the network it not loaded very heavy it will send larger
packets to increase efficiency, it gets retries it makes the packets
smaller. If the networks are built with redundant paths it is also self
healing when a particular link fails. The users do not need any knowledge of
the backbones to use this. The only disadvantage to flexnet that I have seen
is the inability to have node alias calls. You have to know the actual call
with ssid to get where you want. The nodes have provisions for loading a
text file that has the call sign and location information but that requires
the node operators to maintain the file manually. Here are a couple of links
to flexnet information http://pages.sbcglobal.net/kb5iwt/flexdir.htm and
http://www.northeastflexnet.org/.
Brian, N2KGC
-----Original Message-----
From: AE5PL Lists [mailto:HamLists at ametx.com]
Sent: Wednesday, December 29, 2004 10:24 AM
To: TAPR APRS Mailing List
Subject: RE: [aprssig] NetNodes, the future
> -----Original Message-----
> From: Robert Bruninga
> Posted At: Wednesday, December 29, 2004 8:51 AM
> Subject: RE: [aprssig] NetNodes, the future
>
> responsible for.. What could be simpler...
The IGate system currently in place where a user needs NO knowledge of
local "nodes". You might want to take the time, before another inane
reply, to study what they are doing in Germany like I recommend in my
first post.
> >It sure would be nice to get back to KISS and ENcourage APRS
> use, not
> >DIScourage it.
>
> Sorry, I have to disagree here too on two counts:
So you now want to discourage APRS use? Bob, time to come back to
earth.
Related: I have been monitoring APRS usage world-wide over the past
year. ZERO growth! Usage doesn't appear to have declined, but there is
no more growth (about 40,000 stations and objects over a moving 30 day
average). The more difficult you make APRS to use by imposing
artificial barriers, the more likely that there will be a significant
decline in usage over the next few years. Yes, excessive paths are a
bandwidth problem. Yes, we would like to have independence from the
Internet for SOME of the backbone capabilities. But, there are ways to
handle this without turning away the thousands of appliance operators
who want nothing more than a simple tracking system with some messaging.
Your ways are neither simple nor conducive to bring in new operators.
Yes, the Internet did help speed the demise of TheNet, NetRom, and
RoseNet in the US. It also helped cause the explosive growth in APRS
world-wide. Why would anyone want to use a system where they have to
spend hours trying to figure out how to make a connection and then get a
slow speed, unreliable connection (AX.25 1200 bps node system) when they
could have high speed, reliable communications with minimal effort
(Internet)? If you want to know why WinLink has become popular (and we
are beginning to use it here for ARES), all you need to do is look at
what a user has to do use it (use any standard email software which the
user already has). Bob, that is KISS. RELAY,WIDE is KISS.
RELAY,WIDE2-2 is KISS. I352-2,I302-2, etc. is not KISS. Making
connections via AE5PL-10 from a mobile (or any other station) is not
KISS. Multiple frequencies for APRS operations is not KISS.
Flame away. I have better things to do than pursue this thread further
(like making an APRS midlet for cell phones and supporting APRS-IS).
73,
Pete Loveall AE5PL
mailto:pete at ae5pl.net
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list