OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   12.09.03 10:15l 246 Lines 10740 Bytes #999 (0) @ WW
BID : 1899-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 09, 6/8
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<N2BQF<W4JAX<VK4TUB<
      ZL2BAU<ZL3VML
Sent: 030911/1431Z @:ZL3VML.#80.NZL.OC #:8142 [Chch-NZ] FBB7.00i $:1899-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Global APRS messaging
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 9 Sep 2003 17:40:30 -0400 (EDT)
X-Message-Number: 31

On Tue, 9 Sep 2003, AE5PL Lists wrote:

>You apparently have not kept up with nor understand what and how server
>filtering works.

I understand how global APRS messaging is *supposed* to work.

>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.

If you are saying "ALL messages" in the global sense, then that is exactly
what my broad demand was and we agree.  But if you are saying "all
messages" to someone that meets the range-only filter, then we must
continue this discussion.

>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.

Ah, and how is that determined?  The path to an intended message recepient
has nothing to do with position or range, or any other factor that is
dependent on position data.  It was designed to be dependent on an IGate
(anywhere on the planet) having heard the intended CALLSIGN on its RF
side.

THe only way this can work on a filtered stream as you describe above is
if the filtered server is going to all the complexity of maintaining a Qxx
construct parser on 100% of every global message packet seen and capturing
for every station on the air, its last known "Igate".  Then and only then,
does it have the knowledge as to what messages to pass through the filter.
If IGates are that smart, then I applaud the authors and you have again,
met my demand.  But if it is based on the "reported position of the
target, then you are down the slipperly slope of deviating from the intent
of the global messaging of APRS and putting holes in the system's
integrity.

>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.

Depends on how you define "range"... See Paragraph above... if "range"
means "anything it has heard via RF" then we are in complete agreement.
If it is based on a geographic position, then we have a big problem, or we
need to make sure everyone knows that the basis of global APRS message
delivery has been changed by some IGate authors.

>>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.

I still don't see how.  Unless I am missunderstanding it, you have
unconsciously made a step away from the APRS-IS worldwide APRS message
delivery design, by now adding an additional requirement, that the target
station of a message not only has to have been heard by an IGate, but it
also must have a valid position report that is geographically within some
possible filter limits of the geographical location of that IGate?

If so, I repeat my concern, that this is a dangerous precedent.

I want a person in London, who has stepped off the plane with his D7 to
get a message from his wife immediately, even if his D7 when turned on
is still transmitting a position report from kalamazoo... (this happens
all the time and is exactly why message delivery must be 100% independent
of user position data.

Bob, WB4APR

----------------------------------------------------------------------

Subject: Revised Homeport Proposal
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 9 Sep 2003 18:01:47 -0400 (EDT)
X-Message-Number: 32

After lots of discussion and input, here is my revised proposal:

APRS HOMEPORT:  Those APRS users who frequently travel to distant areas
significantly outside of their local area should define their "homeport"
as the local IGate in the vicinity of their home or friends who care.
Defining one's homeport means that the user asks for his homeport IGate to
list him on it's special GATE-TO-RF list.  Details:

1) The IGate then will accept his distant APRS-IS travel packets as worthy
of forwarding back to RF in his homeport area.

2) At any time, such a user can only have one existing homeport
definition at a time. (Other IGates seeing the request drop him).

3) The IGate is smart enough to NOT loop through any local travel packets
by not gating to RF anyone it has heard also on RF.

4) This homeport concept should be AUTOMATIC and requrire no maintenance
by the IGate operators (they have enough to do already!)...

TO ACTIVATE YOUR HOMEPORT:

Send a message to your local IGate (example, MYGATE-3) using any of these
formats:

   To: MYGATE-3: Message: Set Homeport
   To: MYGATE-3: Message: Set Homeport starting 3 July
   To: MYGATE-3: Message: Set Homeport ending 5 Aug
   To: MYGATE-3: Message: Set Homeport starting 3 July, ending 5 Aug
   To: MYGATE-3: Message: End Homeport.

If the homeport IGate gets this message, the sender gets an ACK and also
then a "Your Homeport is: MYGATE-3", or "Your homeport is MYGATE-3
starting 3 July", etc...  Or it could say, "Sorry, This homeport is full.
It can accept no more packets at this time."
Whatever...

HERE IS THE ADVANTAGE OF FORMALIZING THIS CONCEPT:

1) It should remove the incentive for out-of-area travelers to try to use
WIDE7-7 to get back home.

2) It adds no burden to the network.  If the travler is local, his packets
are local.  If he is away, his packets still only affect HIS neighborhood.
APRS is a local thing.  By keeping the burden of packets local, then any
overuse or problems can be resolved locally too...  LOCAL in APRS means
that area that contains your 50 nearest neighbors.

3) It should encourage the intended use of the IGate system for distant
conectivity and help support that infrastructure.  It might also encourage
people to help support their homeport IGate and owner too!

We have everything we need.  Many of you already do this.  But we must
make it standard operating procedure (get people to reduce their path
length... APRS is LOCAL!) and take the maintenance burden off the IGate
owners...

Bob, WB4APR

----------------------------------------------------------------------

Subject: Re: Revised Homeport Proposal
From: "Wes Johnston" <wes@johnston.net>
Date: Tue, 9 Sep 2003 18:16:25 -0400
X-Message-Number: 33

I give up.... I fail to see the difference in your revision... This is like
a bad game of "who's on first".  After much discussion, we are right back
where we started yesterday.

Wes

----------------------------------------------------------------------

Subject: Re: Revised Homeport Proposal
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 9 Sep 2003 15:28:52 -0700
X-Message-Number: 34

I don't care much about being seen on RF in my local area.  Heck, there's no
one listening on RF in my local area.  I'm generally more interested in
getting to the nearest igate, and showing up on the nearest wide so locals
can see I'm there.   I think a lot of users fall into the same category.
How about a generic path that indicates WIDE+IGATE?  As long as the local
igate has been heard at the digi in the last x minutes, it only repeats to
the local area.  But if the digi's not beaconing and possibly offline, it
fails over to a preset path or maybe just an extra WIDE.

The digi doesn't even need to know what the igate's callsign is or where
it's located, just that it's an igate and it's beaconing.  Of course, you
might want a whitelist feature to avoid messing with unknown or rogue
igates.

Scott
N1VG

----------------------------------------------------------------------

Subject: RE: Global APRS messaging
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 9 Sep 2003 17:31:39 -0500
X-Message-Number: 35

Bob,

>-----Original Message-----
>From: Bob Bruninga [mailto:bruninga@usna.edu]
>Posted At: Tuesday, September 09, 2003 4:47 PM
>Subject: [aprssig] Global APRS messaging
>
>Ah, and how is that determined?  The path to an intended message recepient
>has nothing to do with position or range, or any other factor that is
>dependent on position data.  It was designed to be dependent on an IGate
>(anywhere on the planet) having heard the intended CALLSIGN on its RF side.
>
>THe only way this can work on a filtered stream as you describe above is
>if the filtered server is going to all the complexity of maintaining a Qxx
>construct parser on 100% of every global message packet seen and capturing

Again, you do not understand how range filtering works on a server filter.
The server maintains a list of "last heard" positions for all stations
heard.  When a client or IGate connects to a filter port and specifies a
range, the server then compares each packet's "from" station (and "message
to" station in the case of messages) last known position against the range
filter.  If the "from" or "to" station's last known position is within the
predefined range, the packet is passed to the client/IGate.  Please feel
free to reference http://www.aprs-is.net/javaprssrvr/javaprsfilter.htm for
more information on how server filtering works.

>If it is based on a geographic position, then we have a big problem, or we
>need to make sure everyone knows that the basis of global APRS message
>delivery has been changed by some IGate authors.

Not true.  A sysop has the ability to define a range either in distance or
in hops in most IGate software.  In the DFW area, we see packets being
gated for stations 900+ miles away by software that doesn't have this
control because it heard the station on RF even though the IGate's path
precludes the gated packet from ever making it out to that distant station.
Setting range limits at the IGate is not only necessary, it is critical to
reducing QRM.  Otherwise, let's just set every IGate up to
WIDE7-7,WIDE7-7,WIDE7-7 in the hopes that each IGate will then be able to
cover all of the stations it might see on RF (especially during a band
opening).  The latter is neither wise nor making use of the tactical nature
of APRS.

IGates like digis have a desired coverage area.  Many times, there are
multiple IGates within a certain RF range that service different geographic
areas.  For this to happen successfully, each IGate must be able to, in
some manner, specify the coverage area.  As we continue to grow in numbers,
this ability to limit coverage areas becomes more and more critical.

73,

Pete Loveall AE5PL
pete@ae5pl.net

----------------------------------------------------------------------



Read previous mail | Read next mail


 04.11.2026 22:51:01lGo back Go up