| |
PA2AGA > TCPDIG 23.07.97 01:09l 170 Lines 7361 Bytes #-10282 (0) @ EU
BID : TCP_97_56A
Read: GUEST
Subj: TCP-Group Digest 97/56A
Path: DB0RGB<DB0ABH<DB0SRS<DB0MW<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<PI8APD<PI8WNO<
PI8GCB<PI8WFL<PI8VNW
Sent: 970722/0208Z @:PI8VNW.#ZH2.NLD.EU #:19160 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA38846 ; Tue, 22 Jul 97 01:39:20 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.64/7.1) with SMTP
id AA00003776 ; Tue, 22 Jul 97 03:16:52 MET
Date: Tue, 22 Jul 97 00:11:14 MET
Message-Id: <tcp_97_56A>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 97/56A
X-BBS-Msg-Type: B
TCP-Group Digest Fri, 23 May 97 Volume 97 : Issue 56
Today's Topics:
Fw: Benefits of AX.25 encap... (4 msgs)
Geographical subnetting
jn111x7 JNOS
Listsever problem?
TCP/IP (2 msgs)
Yeah, I have Nos runnin on a 286!
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Thu, 22 May 1997 08:33:23 -0600
From: Dave Maciorowski <wa1jhk@ix.netcom.com>
Subject: Fw: Benefits of AX.25 encap...
Mornin' Bob,
>One of the biggest features of *NOS is also one of its biggest problems.
>By adding pseudo-BBS capabilities, it is trying to compete in the wrong
>market, non-tcp/ip operation. This is a great way to get beginners
>familiar with some of the advantages of tcp/ip, but in reality a tcp/ip
>network consists of linking together a series of tcp/ip hosts.
>
>By connecting via ax.25 to a *NOS station and reading a group of messages
>(which are at least sorted into areas, unlike most BBS software, one is
>doing BBS-style communications, not tcp/ip.
When we built our TCP network here in Colorado (two 9600 baud bit-regen
repeaters covering thousands of square miles, plus gateways covering local
areas), we started off saying "this is a tcp network. Just setup xNOS and
join in." Yeah, well, not many users did.
So, we took a second tack. We built the "CRA Access Menu", a 1200 baud
bit-regen repeater with a simple menu implemented in bash shell scripts.
This lets the hams with their Commodores connect via the hardware they
already have and see the benefits of TCP without having to spend 100's of
hours figuring out how to make xNOS work. FYI, our Access Menu let's users
download popular text files (newsletter, swaplist, Newsline), connect to any
BBS on the local LAN, selected BBSs on the AMPRnet, and the Convers server.
Our traffic increased quite a bit after this. After experimenting with our
Access Menu, some of the users have migrated to TCP. It's become a good
demonstration system.
We view our TCP network as the backbone for many other services. We
carry BBS store-and-forward traffic, telnets to remote BBSs, Convers, etc.
ARES uses the system to access their database server. We are planning to
add APRS gateway services to connect 145.79 ports and Mic-E-equipped voice
repeaters around the state.
>In tcp/ip, messages are delivered directly to the end user's computer and
>a mail agent is used to read/compose. We should be encouraging end users
>to be running some form of tcp/ip software, rather than connecting to a
>local node. Encouraging the use of a simplified form of NOS (which can
>easily be created by not compiling in all the features) or even NOS's
>predecessor NET, might be a way to accomplish this. The addressees of a
>message would have it delivered directly to their own station, instead of
>having to log in somewhere else to read their mail.
The missing link here is the driver/stack for Win95 to make this
plug-and-play. Until this exists, we won't see the migration to tcp.
For the mail scenario to work, the user must be committed to leaving
their computer on all the time. To work around this, our club offers POP
services so they can pickup their mail when they turn the machine on.
Also, there needs to be relatively cheap plug-and-play rf modems for
higher speeds. Our experience is that while a 9600 baud bit-regen repeater
provides acceptable thruput, many users expect 28.8 performance. Our plan
is to install a 56kbps bit-regen repeater, but at the current $700-$1000 per
user station, it won't have many users.
Like most tcp'ers, I have many machines on a local ethernet with a
Linux router to the 9600 baud repeater. But, we can't expect the users with
old machines to participate at this level.
73,
Dave
-----
Dave Maciorowski, WA1JHK
Colorado Repeater Association, Inc.
Serving Colorado with Voice and Data, 6-Meters to 1.2 Gig
Internet: wa1jhk@ix.netcom.com or wa1jhk@amsat.org
CRA: http://www.rmsd.com/hamradio/cra/
------------------------------
Date: Thu, 22 May 1997 09:46:04 -0600
From: jra1854@tntech.edu (Jeffrey Austen)
Subject: Fw: Benefits of AX.25 encap...
Thanks, Bob, for providing some food for thought. I'd like to add some
observations to that.
[cut]
>By connecting via ax.25 to a *NOS station and reading a group of messages
>(which are at least sorted into areas, unlike most BBS software, one is
>doing BBS-style communications, not tcp/ip.
>
>In tcp/ip, messages are delivered directly to the end user's computer and
>a mail agent is used to read/compose. We should be encouraging end users
>to be running some form of tcp/ip software, rather than connecting to a
>local node.
[cut]
OK. I KISS-ize my TNC (if possible), buy a cheap old computer, obtain a
copy of one of the seemingly infinite variations of NOS, get an IP address,
and after a few wasted evenings call up a friend and get her to come over
and help me install it. Then what can I do?
Telnet to a BBS.
Great. Really great.
There are at least two problems here: it's too hard and the rewards are too
few.
Installing and configuring IP could be made much simpler. Wired networks
are now using address negotiation (via PPP), BOOTP, DHCP, etc. to make
configuration automatic. We're still assigning static addresses. There's
little flexibility and no support for mobility. It's a pain for the person
assigning them and it's a pain for the person using them. If the software
were "plug and play" more people would at least give it a try.
The second problem is that IP offers little advantage over AX.25 or other
packet protocols. Sure, one can telnet and ftp at the same time (which
would, of course, when done on a 1200 b/s link be sure proof of insanity)
but is that really what users want? The really growing parts of packet
radio are APRS, DX Cluster and Converse nodes. Do these exist for IP? Where
are even better applications?
A third problem is that things don't work. Radio-based IP breaks some
crucial assumptions that are fundamental to the protocol stack design. We
haven't fixed those yet. An end-to-end connection is often difficult and in
some cases impossible to obtain. In almost any comparison the BBS
forwarding network puts the IP network to shame -- it may be slow,
To be continued in digest: tcp_97_56B
Read previous mail | Read next mail
| |
