| |
ZL3AI > APRDIG 12.09.03 10:13l 236 Lines 10652 Bytes #999 (0) @ WW
BID : 1898-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 09, 5/8
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0IUZ<DB0GOS<ON0AR<ON0AR<ZL3VML
Sent: 030911/1424Z @:ZL3VML.#80.NZL.OC #:8141 [Chch-NZ] FBB7.00i $:1898-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Homeport
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 9 Sep 2003 16:05:22 -0400 (EDT)
X-Message-Number: 26
>if we are smart, we'll put the smarts in the system, and let the
>trackers and other clients be relatively or completely 'dumb'.
Now this is approaching a religious argument <grin>. Let me expound.
The problem with the Power grid, Windows, the modern Automobile and just
about everything these days is that we have smart engineers trying to put
every imaginable smarts into everything so that the users can be as dumb
as possible and not have to even think. DUh...
That is what causes Blackouts, Crashes, Tow trucks, and people locked out
of their house because the battery in their garage door opener died.
The number one thing we can do as a society is not try to dumb everything
down so that stupidity reigns. We need to include the thinking human
being in the loop as much as possible so that he "learns" what he is in
the middle of and can adapt and react to changing circumstances and not
become helpless when the slightest un-thought-of input condition occurs.
My experience is that EVVERYTHING AUTOMATIC does more often than not,
exactly what I DONT WANT TO DO at that moment. THen I have to fight the
STUPID engineering of the thing to get it to do what I NEED It to do right
now. Lets KISS, Keep it simple stupid...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Homeport
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 9 Sep 2003 15:14:02 -0500
X-Message-Number: 27
Bob,
You apparently have not kept up with nor understand what and how server
filtering works. You make a rather broad demand here without knowing
that, in fact, global messaging is supported EVEN on range-only filtered
ports. Let me explain...
First, port 1314 may be used as a filtered port for IGates. It passes
ALL messages and associated posits PLUS anything defined in a filter
command. This negates the need for setting t/m in the filter.
Second, someone connecting to port 14580 with an IGate which is only
using a range or area filter WILL receive all messages addressed to
stations within that range. Therefore, if an IGate sysop only wants to
serve a specific range (not all IGate software has range/hop limits),
they can while still providing world-wide messaging for the RF stations
within the range.
So contrary to your statement below, not all IGates HAVE to see ALL
messages on APRS-IS in order to provide world-wide messaging to stations
within their coverage area.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Diff between homeport and path designator methods
From: "Wes Johnston" <wes@johnston.net>
Date: Tue, 9 Sep 2003 16:15:53 -0400
X-Message-Number: 28
From: "Bob Bruninga" <bruninga@usna.edu>
>Thus, I see no need for opening up all kinds of processes for TARGETing
>Igates for being flooded from afar, other than in the case of HOMEPORT
>which is a request by a local for packets back to his own area, which I
>contend is a far less complex and dangerous issue.
I don't want this to come across as a personality issue... so bear with me
please....
Bob, I suggested simply putting the city code - or whatever designator we
agree upon - in the unused path elements. For example: RELAY, WIDE, SMS,
ATL would deliver my packet to SumterSC and AtlantaGA. You suggest
registering a homeport - one IGATE which will be your "home' and only that
igate will gate your data to RF. If you register with a 2nd homeport, the
first one will see the message and realize it's no longer supposed to be the
igate for you anymore.
As far as I've been able to tell, your (well founded) concern is that users
will unwittingly flood some distant town with too many packets and
unknowning saturate the distant network. What I can't understand is how
will designating a single IGATE for your outbound packets curb this
behaviour? If I register atlanta as my homeport, I can still flood atlanta
from here. The homeport registration does nothing to stop that.
If I'm on target so far (i'm going out on a limb b/c I think I am on
target), the overhead involved with registering and unregistering, igates
going down and rebooting, making sure that the registration messages are
sent periodically, etc... etc... I really think that it's just easier to
simply list the citycode designator (did we settle on a grid square naming
convention?) as an extra path element. Let's leave the RF flooding control
to the igates to manage.
Even from way back in 1995 you wrote this:
LEVEL FOUR NETWORK CONSIDERATIONS:
Since NODES are so much smarter than digipeating, the ultimate
solution is to have the NODES do all UI frame routing via high speed
backbones. The APRS station simply sends his UI frame TO APRS VIA HOME;
Any NODE hearing that transmission that has knowledge of the route to
HOME, will send the single packet via the NODE network (level 4) to the
HOME node! When it arrives at the HOME node, it is transmitted once as
a UI frame. With this arrangement, a mobile only has to specify his one
intended destination, no matter where he travels!
I am simply suggesting that we stick to this model... there is no need for a
2nd message type to designate a homeport. Just do it in the path as listed
in the paragraph above. The mysterious undefined "backbone" mentioned is
the aprs-is and it's TNC is an IGATE...<grin>.
respectfully,
Wes
----------------------------------------------------------------------
Subject: Re: Homeport
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 09 Sep 2003 15:30:06 -0500
X-Message-Number: 29
>My experience is that EVVERYTHING AUTOMATIC does more often than not,
>exactly what I DONT WANT TO DO at that moment. THen I have to fight the
>STUPID engineering of the thing to get it to do what I NEED It to do right
>now. Lets KISS, Keep it simple stupid...
then you put the power back in the hands of the users, who have shown that
they cannot and or will not learn.
i am my own best example here.
i use aprs when i need it, but it's not something i do frequently.
when something has changed, i'm usually not up on it.
when i drive, i do not, and most likely will not, adjust my tracker.
my normal 'commute' these days is about 900 miles, crossing 5 or 6 states.
i'm not saying that we could, or even should, prevent the user from doing
whatever they can reasonably do, but your car has fuses to prevent you
damaging the network by holding down the window switch for 30 minutes. it
has lockouts that prevent you from hitting roll-up and roll-down at the
same time..
----------------------------------------------------------------------
Subject: Re: Diff between homeport and path designator methods
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 9 Sep 2003 17:16:06 -0400 (EDT)
X-Message-Number: 30
On Tue, 9 Sep 2003, Wes Johnston wrote:
>From: "Bob Bruninga" <bruninga@usna.edu>
>>Thus, I see no need for opening up all kinds of processes for TARGETing
>>Igates for being flooded from afar, other than in the case of HOMEPORT
>>which is a request by a local for packets back to his own area, which I
>>contend is a far less complex and dangerous issue.
>
>As far as I've been able to tell, your (well founded) concern is that users
>will unwittingly flood some distant town with too many packets and
>unknowning saturate the distant network. What I can't understand is how
>will designating a single IGATE for your outbound packets curb this
>behaviour? If I register atlanta as my homeport, I can still flood atlanta
>from here. The homeport registration does nothing to stop that.
It is the matter of "intent". Sure, anyone can be creative in figuring
out ways to abuse the system, or for that matter, to use it for creative
things, but I am saying that we create the Homeport concept for its
intended purpose, and that is its published intent.
Then since all of you are so convinced that APRS operators are such
dummies that they dont have a clue how the system works, then they will
either use the homeport concept as stated or not. Then those that figure
out cereative ways to use it is a different kettle of fish.
>If I'm on target so far (i'm going out on a limb b/c I think I am on
>target), the overhead involved with registering and unregistering, igates
>going down and rebooting, making sure that the registration messages are
>sent periodically, etc... etc... I really think that it's just easier to
>simply list the citycode designator (did we settle on a grid square naming
>convention?) as an extra path element. Let's leave the RF flooding control
>to the igates to manage.
Great ideas, but they dont (in general) manage all the existing problems
much less laying another problem at their feet. Great ideas sometimes
turn into nightmares when haphazardly and inconsistentlyh implemented.
>Even from way back in 1995 you wrote this:
>LEVEL FOUR NETWORK CONSIDERATIONS:
>
> Since NODES are so much smarter than digipeating, the ultimate
>solution is to have the NODES do all UI frame routing via high speed
>backbones. The APRS station simply sends his UI frame TO APRS VIA HOME;
>Any NODE hearing that transmission that has knowledge of the route to
>HOME, will send the single packet via the NODE network (level 4) to the
>HOME node! When it arrives at the HOME node, it is transmitted once as
>a UI frame. With this arrangement, a mobile only has to specify his one
>intended destination, no matter where he travels!
>
>I am simply suggesting that we stick to this model...
And that is 100% exactly what I am suggesting here! "HOME" in the example
above means "INSERT YOUR LOCAL "node" CALLSIGN HERE"...
>there is no need for a 2nd message type to designate a homeport. Just
>do it in the path as listed in the paragraph above. The mysterious
>undefined "backbone" mentioned is the aprs-is and it's TNC is an
>IGATE...<grin>.
Yep, and I agree with this. But it turns this current discussion into a
level-4 turn-the-APRS-IS-into-a-directed-path-system which I have tried
to promote in the past and have run up against brick walls on the part of
the APRS-IS gurus. Thus my proposal for HOMEPORT accomplishes the same
thing, but "within" the currently accepted APRS-IS operating structure,
so that it doesnt get bogged down in the religious wars of trying to
change the way the APRS-IS works. I have all but given up on that...
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
