<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Two issues here....<br>
1)I've seen users run crazy paths because they either didn't know any
better, or they were locked out by the sysops (budlisted) due to abuses
they did not resolve. This in turn leads them to run really really
stupid paths. Case in point was a station in NC who was so
aggrivating, he ended up budlisted by all the local digipeaters. His
response was to run RELAY,RELAY,WIDE,RELAY at 160watts. On the one
hand, this "creativity" is a testament to how robust the aprs "p2p"
network is! On the other hand, the entire situation could have been
avoided if the NETWORK was smart enough to re-write the guy's path to
something more acceptable. The end result would have been that his
packet would have been seen as far away as prudent, and there would
have been no feelings hurt because he never got budlisted.... matter of
fact, many many newbies don't pay attention to paths at all, so would
be blissfully ignorant of the on-the-fly path changes that could have
been made. Pete's NSR system does just this.... it takes whatever path
is found in a packet, removes it and substitutes the callsign of the
digi that heard the packet first. All surrounding digipeaters that
consider that first digi's geographic area to be local to them will
digipeat the packet. His system even permits overlapping coverage
areas! For example, packets originating inside a city could be
digipeated outward, while packets originating outside the city would
not be brought into the busy city. He's even figured out how to use
IGATES to still permit messages into areas that normal position reports
would be too much.<br>
<br>
I did say in the above paragraph that "packet would have been seen as
far away as prudent".... One of my first objections to Pete's NSR
system at first was what if I don't want my packet to go out the full
number of hops permitted in the aloha circle... but when I really
thought about it, who really does this? For all but a few APRS
operators, paths are "set and forget".... and often times set higher
than needed for those occasional cases where you might need it. Heck,
I'm a good example of this.... I set my path to WIDE1-1,WIDE2-2 to
cover my occasional trips to the upstate of SC. Only yesterday did I
realize that 3 hops got me nearly to Tampa FL! With Pete's system, the
NETWORK can adjust your hops as needed. <br>
<br>
The really slick part is that it can be implemented smoothly over
time.... the users don't have to do anything.... you can run whatever
path you wish in your car or your home... if you are in a normal aprs
network, the path is utilized. If you happen to wander into a NSR
network, the network will remove your path and route your packet over
an acceptable area (ie your aloha circle)<br>
<br>
Just think, if we had NSR everywhere _today_ we wouldn't be screaming
about the long haul truckers running W4-4 W5-5 here on the east coast
for those cases when they are out west and need 4 hops! With NSR in
place, let 'em run crazy paths.... the digipeaters will politely fix
the paths and keep the stations 'in' the network. <br>
<br>
While implementation of NSR can't be done on your run of the mill KPC3,
it can be done with digined and a cheap laptop hooked to your kpc3. I
suppose Kantronics could implement it in a firmware revision though....
it's simply a matter of removing the path from any packet heard direct
and substituting the digipeater's callsign. A list of "friendly"
digipeaters needs to be maintained so that when a packet comes in that
has been digipeated by a neighboring digi, it is digipeated. That's
really it in a nutshell.<br>
<br>
<br>
--------------------------Next point---------------<br>
<br>
2)forcing packets out an igate has been discussed before... the
problem is that inevitibly you'll have 10 people "pushing" packet out
into some large city like LA where the network is already saturated. I
think a better solution is to let someone in the area register (or
subscribe) with a local IGATE for certain data products. What would be
slick is if the tracker in my car could send this subscription message
periodically, say mixed in with my positions every 10 minutes. Upon
hearing this subscription request, the nearest IGATE to me would send
my requested data for the next 30 minutes. The end result of this is
that the data I want to see from a far away place would appear (to me)
to follow me around. From a fixed station's perspective, the data I
requested would appear for a short time and when I left town, my data
would not clutter the network any more. Also, subscribing to data
"pulling" would allow the person on the recieving end the option of
stemming the flow of out of area data if they felt the network was
nearing saturation. IGATES already keep dynamic lists of what they
will and won't gate out to RF.... they keep a list of stations that
have been seen locally and gate messages out to those stations as the
messages come along. This subscription thing would be no different
than that except that users on RF would be able to tell the igate other
things (other than just messages) they wanted to see on RF.... like the
location of another car in another country.<br>
<br>
Wes<br>
<br>
AE5PL Lists wrote:
<blockquote
cite="mid478F6623898BBC4DBD692A223D28298A165159@amewebsrvr.webametx.local"
type="cite">
<pre wrap="">What "limitations in the current Internet backbone" do you think flexnet
would fix? The problem with flexnet is that it is still source routing
under a different name. Let me ask you a simple question regarding your
IGate example: can you, in today's telephone and Internet networks,
force a connection to a remote speaker phone telephone or to a remote
computer if those remote devices do not answer you request? The answer
is no. Yet, you think it is perfectly all right to force that remote
IGate operator to gate your packets to RF just because you say so in
your path? Again, this is source routing and should be eliminated
_completely_ from the APRS network so that the APRS network can go to
the next level and be a truly useful mode of communications instead of a
just a toy for a few hams to play with.
As I pointed out, the way you get there is to eliminate the need for any
user to have to configure more than their callsign-SSID and how they get
their position information into their software/hardware. From there,
the network should be able to distribute that information without
further interference from the user. The second you introduce any type
of paths, including destination "areas", into the equation for a
broadcast-type protocol, you will fail to achieve a stable and reliable
network because it now depends on thousands of users getting it right
(which won't happen nor has it ever happened).
73,
Pete Loveall AE5PL
<a class="moz-txt-link-freetext" href="mailto:pete@ae5pl.net">mailto:pete@ae5pl.net</a>
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Andre PE1RDW
Posted At: Thursday, June 09, 2005 9:08 AM
Subject: Re: [aprssig] New Digi Settings
As long as we are talking about "new" routing options, why
not throw in flexnet routing to overcome some limitations in
the current internet backbone.
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
</body>
</html>