| |
PA2AGA > HDDIG 23.09.99 04:52l 156 Lines 7899 Bytes #-9769 (0) @ EU
BID : HD_99_237K
Read: GUEST
Subj: HamDigitalDigest 99/237K
Path: DB0AAB<DB0ZKA<DB0ABH<DB0BOX<DB0MAK<OK0PKL<OK0PPR<OK0PRG<OK0PAB<HA5OB<
HA3PG<SV1AAW<EA7URC<PE0MAR<PI8VNW
Sent: 990922/2141Z @:PI8VNW.#ZH2.NLD.EU #:1453 [HvHolland] FBB7.00g $:HD_99_237
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19514 ; Wed, 22 Sep 99 20:52:46 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00015780 ; Wed, 22 Sep 99 21:18:34 MET
Date: Wed, 22 Sep 99 21:15:39 MET
Message-Id: <hd_99_237K>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/237K
X-BBS-Msg-Type: B
clique of self-absorbed geeks who are so ignorant themselves that they just
can't understand basic stuff, like why hams would want to use radio to
communicate... Duh!
I've been aware of one method for effectively bridging those gaps between
packet nets for a several years now, and recently discovered another one.
Either idea would work, but both need to be developed. One has been around
for years, and fell into the TAPR "black hole"; That limbo within TAPR,
where projects the LandLine Lid types do not want developed end up at. The
other has not been developed because I just thought of it a few months ago,
and I'm as capable of being lazy and worthless as anybody.
"Takes one to know one!" Yep, I was one of the pioneer "LandLine Lids",
too, back in the pre-Internet days. Ask me about it, sometime. Since I
learned my lesson and moved on to better things, I figure that I don't have
anything to be ashamed of.
Doing it after you realize how destructive it is, be it out of pride,
laziness or stubborn-ness.... That's shameful.
Moving right along...
HF Multicast:
AMSAT uses multicast for it's dirtside BBS's, and the NWS uses multicast for
it's VHF EMWIN broadcasts. It's a proven concept that's been around a while,
but not used yet on HF. - We could pioneer that, you know... Make a
contribution not only to other hams, but to people around the world. We are
not by any means the only ones who would benefit from the development of HF
multicast. Why not continue the old tradition among hams of making
significant contributions to the world's ability to communicate effectively
with radio? IMHO, we should NEVER pass up opportunities like the one
presented by HF multicast.
Here's how HF multicast could solve or greatly ease our problem with
those wide open spaces between packet LANS:
Multicast is basically one transmitting station distributing data to an
unlimited number of unconnected receiving stations. It's a broadcast system.
I checked with the ARRL rules 'n regs guys before doing the first
experimental HF multicast transmissions last year, and they assured me that
it was as legal as church on Sunday, and make sure you don't get caught.
Being on HF, the HF multicast server operates at the standard 300 baud, but
still distributes information over wide areas at a speed that is faster than
point-to-point forwarding of packet messages by several orders of magnitude.
You just can't build a VHF/UHF point-to-point network that will distribute
the data over a large area at a speed even approaching that of HF multicast,
since multicast delivers the data to a large number of stations located
within a significant chunk of the planet, all at once.
It's like the difference in speed between your computer's serial and
parallel ports, or the difference between a computer with a single CPU, and
a parallel processor computer with multiple CPU's.
This is because multicast utilizes parallel routing instead of the serial,
point-to-point routing we have all become familiar with. The concept is
really simple, elegant, cheap, and very effective.
The ability of a single HF station to be simultaneously heard by many
receiving stations located over a significant chunk of the planet is one of
those "magic" things that HF radio does that nothing else can. It's our job
as hams to identify, develop and pioneer these advantages that radio offers,
not to sit on our hands and whine out a chorus of "it can't be done", or "it
has to be tcpip".
The greatest benefactors of HF multicast will be hams who are located in
remote areas and who have little by way of resources to work with. - That's
what Ham Radio is all about, folks.
For more detailed info on this, see the article "HF Multicast - Super Fast!"
on my web site, in the "Articles" section. It covers many issues there is
not
room to cover in this usenet posting.
All Band Networks:
This is another idea for bridging those wide open spaces, not as good as HF
multicast but still practical and it requires no actual development. It's
just a more clever way of using the tools we've been using all along. It
also involves parallel routing but not nearly to the same degree that HF
multicast does.
HF forwarders love large-scale VHF/UHF networks, because they simplify the
routing so much, and greatly expand the area a particular HF forwarding
station can serve. For example: As an HF forwarder, I don't have to connect
to a BBS in New York, in order to deliver a message bound for Long Island...
Since the NEDA VHF/UHF net covers a number of states including New York, I
can forward the message to any of those states NEDA covers (New Hampshire
will do nicely) and be confident that the message will end up on Long Island
in short order. - And since I live within the coverage of a large-scale
network myself, I can accept and distribute messages to Texas, Oklahoma,
Missouri and Arkansas in a timely fashion. This is the way that VHF/UHF nets
greatly expand the capability of HF forwarding stations. It's actually much
more
powerful than I just made it look with this brief explanation.
My idea is simple: Instead of calling them VHF/UHF networks, why not
organize what is already being done anyway and call them HF/VHF/UHF
networks, or "all band networks", and take control of a process that has
been allowed to go on for years in an uncontrolled, unorganized fashion?
If each large-scale network had a "HF coordinator", then multiple HF
stations within the network's coverage area could be recruited and organized
so as to eliminate duplicated efforts and organize forwarding chores with HF
stations associated with other VHF/UHF nets.
The same thing can, of course, enhance the effectiveness of AMSAT BBS's and
they have already taken a step in this direction by assigning individual
AMSAT BBS's to serve large geographical areas. I believe that AMSAT already
does what it can to locate these stations within the coverage area of
large-scale VHF/UHF nets, but I'm not certain.
With this little bit of organization, routing problems can be more easily
identified and dealt with, and it is possible to gain a speed advantage.
If there is no route to the south, one can be deliberately developed. If the
mail from the west is more than one HF forwarder can handle, additional
stations within the LSN (Large Scale Network) can set up forward to the west
for a "parallel routing" effect. It won't be as flabbergastingly efficient
as multicast, but it still does something that the usual way of doing things
cannot, and would serve to greatly enhance the connectivity between large
scale VHF/UHF nets.
I think it's pretty obvious that developing RF connectivity between LSNs (or
LANS, if you prefer) should be one of our very highest priorities, most
especially because it is something that hasn't been done yet.
The point being made here is that if an appliance operator from Pottsboro
Texas can see a couple of reasonably viable ways to attack the problem, that
means that other, more knowledgeable hams could do a lot better!
The problem of communication between distant LSN's will never be solved
though, by the "it can't be done" attitude being spread around the packet
community by TAPR and the LandLine Lid clique. Gloom 'n doom never got a
damn thing accomplished, which is why I keep suggesting an organizational
enema for TAPR. After the enema, the organization will have a lot better
attitude and will be ready to once again serve the interests of US hams, as
To be continued in digest: hd_99_237L
Read previous mail | Read next mail
| |
