| |
ZL3AI > APRDIG 02.10.03 10:17l 226 Lines 9220 Bytes #999 (0) @ WW
BID : 2046-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 2/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0SIF<DB0FHK<DB0ACC<DB0GOS<ON0AR<ON0AR<
VK6HGR<VK3AVE<ZL2BAU<ZL3VML
Sent: 031001/1335Z @:ZL3VML.#80.NZL.OC #:9446 [Chch-NZ] FBB7.00i $:2046-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: LANn-N routing.
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Sep 2003 09:18:41 -0700
X-Message-Number: 7
You're right, routing smarts belong in the network and not in the client.
I'd like to see some more discussion on a UHF overlay and what form it
should take, and what relation it'll have to 144.39.
SSB with PSK would be great, but I think the problem is lack of equipment.
Who runs SSB on UHF? And I've never seen a handheld with SSB capability.
It'd be cheaper (and simpler) to run multiple input channels at 1200 baud
and a single output channel at 9600. And I still don't have any portables
capable of 9600, but at least they're out there. Actually, even a single
buffered 1200 baud output channel would be able to handle a lot of stations,
especially if it had the smarts to prioritize its output queue, dropping
dupes and giving priority to mobiles.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 12:45:02 -0400 (EDT)
X-Message-Number: 8
On Mon, 29 Sep 2003, Wes Johnston wrote:
>What if ..... you got dupes from a station which you knew was
>LOCAL. Rather than dropping the packet on the floor if it's a dupe, modify
>it's path (ie set the HID flag in all digipeater slots, and decrement all
>wideN-N counters) so that it will not be digipeated by the next digipeater
>in the chain. In this way, we have the ability to send as many redundant
>packets as we want, ONLY in our LOCAL area. This way, if someone is
>flooding our local network, we can get to him and wring his neck, but if we
>really really need to flood our area, we can.
Makes no sense. We have got to get APRS users to realize that DUPES are
part of the distribution process. If an initial packet hits 3
digipeaters, then there are 3 copies. The next 6 or 8 beyond them all
make a copy too... That is how packet propogate. Peole will hear some
multiple copies.
If someone's antenna is high enough and there was a PERFECTLY EFFICIENT
WIDE3-3 packet propogated, he would see 21 to 36 copies depending on the
density of digis in his area.. These are not dupes, they are the normal
process...
Nothing is broke except for users not understanding that it is a shared
resource and NO ONE should be propogating packets beyond his 50 nearest
neightbors.
de WB4APR
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: Re: LANn-N routing.
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 13:11:59 -0400 (EDT)
X-Message-Number: 10
On Mon, 29 Sep 2003, Scott Miller wrote:
>You're right, routing smarts belong in the network and not in the client.
When you talk "routing" issues, it is kinda like going back and
re-inventing Packet Radio. We did that from 1978 to 1994 where we had
evolved to the pinacle of a level-4 Ham Radio Packet network, that could
"route" packets anywhere on the planet (point-to-point) and do a good job
of it.
But that is why I had to SPIN off completely, and break that point-to-
point "routing" way of thinking and to fight all the naysayers to develop
APRS. APRS uses a one-to-all delivery system that has NO ROUTING issues.
Its job is, and remains, to make sure that everyone in the LOCAL LAN gets
a copy of EVERYTHING in his LAN. That is ALL-to-ALL communication. Think
tactical-real-time-communications system.
There are no "routing" issues in APRS. Everyone gets a copy, and all APRS
packets are *supposed* to flood the LOCAL net. There will be dupes.
The ***problem*** we are having is that fewer and fewer users are aware
of the limitations of such a system and how the LAN must be BOUNDED so
that there are not too many people pusshing too much data into too large
an area.
As soon as you start talking "routing" then it is NOT APRS, and not a
tactiacl real-time all-to-all network. It is something else, (quite
similar to AMateur Packet Radio)... As I have always said. APRS *needs*
to operate *in-conjunction* with a conventional packet system. APRS is
very low data throughputs, but EVERYONE is instantly informed. THen let
all the other point-to-point traffic go on the OTHER amateur Packet
systems.
So much I hear of all these other "routing" and Heirarchical, and network
control issues are now what APRS is about. ALl great discussions, but I
want to FIX APRS. And we should not cloud that issue with all the other
great networking theories that we could come up with.
APRS is a tactical REAL-TIME local system who's intent is to have everyone
participating in an EVENT or situation to have INSTANT reliable access to
the tidbits of information that everyone needs to see in real time. It
MUST be dependent on come-as-you are digipeating and NO RELIANCE on any
kind of unique or special setups or routing or key
single-points-of-failure....
Bob
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: aprsca.net down?
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Sep 2003 10:43:20 -0700
X-Message-Number: 12
I just checked my Xastir display and saw a bunch of interface errors - I
can't seem to connect to aprsca.net and it doesn't respond to pings. Is the
system down?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
From: "Spider" <spider@rivcom.net>
Date: Mon, 29 Sep 2003 10:42:19 -0700
X-Message-Number: 13
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, September 29, 2003 9:45 AM
Subject: [aprssig] Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
>Makes no sense. We have got to get APRS users to realize that DUPES are
>part of the distribution process. If an initial packet hits 3
>digipeaters, then there are 3 copies.
Seems to me there is a big mis-understanding on how APRS attempts to insure
a packet makes it to where it was suppose to go versus a 'connected' mode of
packet operation.
I see the comments about changing from 145.xx (which in many cases was a
connected mode) and going to 144.39 APRS (which is unproto). Yet, folks
seem to think they do the same things and have applied trains of thought to
APRS networks that they might have had with their connected networks.
Well, they are not the same concept at all.
Jim, WA6OFT
"Doing the same thing over and over and over again, expecting the same
results, is insanity!"
----------------------------------------------------------------------
Subject: Re: LANn-N routing.
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Sep 2003 10:52:38 -0700
X-Message-Number: 14
Ok, I think we're having another semantics problem like the digi vs. node
thing. I'm not talking about point-to-point unicast routing alone - by
routing I'm also referring to broadcast/multicast/geocast methods. True
broadcast probably has no place in APRS - nothing you send out on RF is
going to be of interest to the entire planet. More likely you're interested
in a geocast to a specified area(s), or multicast to specific groups, e.g.
SAR, boyscouts, and so on.
My point is that the client should worry about defining the intended
audience for its messages, and let the network worry about getting them
there as efficiently as possible. If I'm driving across the country with my
TT3, I want it to announce my location for maybe 50 miles on RF, and to the
nearest IGATE. I shouldn't have to worry about how many WIDEs to use, or
what LAN I'm on.
Scott
N1VG
----------------------------------------------------------------------
Subject: Help with APRSd 2.2.5-14 and RedHat9
From: "Michael J. Wolthuis" <wolthui3@msu.edu>
Date: Mon, 29 Sep 2003 13:55:53 -0400
X-Message-Number: 15
Everyone,
We recently upgraded to a new machine and Redhat 9 and not have some
problems. This is not our primary IGATE, but our secondary backup at
our National Weather Service. I need to get it fixed ASAP!
As currently set up on the RH9 box, the APRSd will start and run, and
from the feedback it sends to STDOUT appears to be receiving and
processing APRS packets okay. The problem now is that as soon as you try
to look at the data on IP port 14579, APRSd terminates. This occurs if
you try to open a socket to any of the ports APRSd uses, like 1313 and
14580. It occurs no matter if the attempt is remote or from localhost.
I'm wondering if there is a compiler switch I need to set to get gcc to
compile this correctly to work with the IP stack, or if there may be a
naming issue with some stdlib functions. Or it could be something in the
aprsd.conf file just isn't set right.
Any help or suggestions would be greatly appreciated.
Thanks,
Mike Wolthuis
Kb8zgl
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
