Date: Sat, 13 Mar 93 04:30:10 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #69
To: tcp-group-digest
TCP-Group Digest Sat, 13 Mar 93 Volume 93 : Issue 69
Today's Topics:
mailer bouncing
Re: In-Reply-To: Re: hidden transmitter routing
token ring pd
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 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: Sat, 13 Mar 93 06:44:41 GMT
From: ki6cq@w6ue.caltech.edu
Subject: mailer bouncing
To: tcp-group@ucsd.edu
hope i havent caused any problems for the list. i discovered today
that the mail was being bounced for a while. maybe i need a cname or
some other line in my domain.txt or something in rewrite. i am running
on both ethernet and net44, and the mail problems occur when using the
net44 address for the ipaddress and ifconfig'ing the eth port to get it
to work.
73 de Paul KI6CQ
------------------------------
Date: Thu, 11 Mar 93 18:25:21 EST
From: chas@chas.nusc.navy.mil (Charlie Greene, W1CG)
Subject: Re: In-Reply-To: Re: hidden transmitter routing
To: tcp-group@ucsd.edu
Fred writes:
>
>Anything with repeaters is going to be far, far superior to any new
>contention scheme designed to run single-frequency. All this stuff
>about tokens and slots et al are basically fighting a losing game in
>the radio environment. The voice guys had the answer (repeaters) a few
>decades ago.
To solve a problem, one must first define it. Fred has an elegant
solution to the problem of a centrally located server on a mountain top
where no users hear each other (pure Aloha). How about the situation
where we have a "nation wide packet data backbone network"
"particularily with higher data rates" in the 219-220 Mhz band, to
pharaphrase ARLB025. The band is too narrow to permit repeaters. The
problem is how to get from point A to point Z when every other node
cannot hear each other. Example: A, B and C are in a line. A and B
cannot hear each other; C hears both. Because A and C are HTS to each
other, each clobbers the other in B's receiver. Here's another hardware
only elegant solution. KA9Q first proposed it in a Computer Networking
Conference paper a few years back. The concept is that each site has
only one transmitter but as many receivers as other nodes he wants to
hear.
Example: Node A transmitts on 430.15 and B receives A on 430.150. Node
B transmitts on 430.250 and both B and C receive A on this frequency.
Node C transmitts on 430.250 and B receives C on 430.250. The mode of
operation is simplex, so when B is transmitting he is not listening on
either frequency. But A and C both listen on B's frequency and don't
transmit when he is. So no HTS. To implement this, all nodes need only
one transmitter but B needs two receivers.
The network can be extended from Maine to California using only 430.15
and 430.25. Each node receives its neighbors on a different frequency
and transmitts on only one of the two frequencies. The reason 430.15
and 430.25 are selected for the example is that they are 100Khz channels
in the ARRL band plan.
Another way to solve the same problem but on a more limited scale: A
and C above are (digital regenerative) repeaters, B is a user of both
repeaters and acts as a link between them. Data rate is limited to 9600
on 440. I bring this up because it is currently being done in NE,
between the Central MA TCP/IP repeater and the Connecticut TCP/IP
repeater.
All please bear with me for awhile as this is the first time I have sent
anything to this forum although I have read the mail for some time now.
*
*
************************************************************************
* chas@mvangel.nusc.navy.mil -- Internet *
* W1CG@BBS.WA1PHY.#EMA.USA.NA -- AX25 *
* w1cg@switch.nptri.ampr.org -- AMPERNET *
* Charles Greene, 115 Aaron Ave, Bristol, RI 02809 -- US MAIL *
************************************************************************
------------------------------
Date: Fri, 12 Mar 93 21:53:35 PST
From: bob%n0qbj.tcman.ampr.org@skeggi.vware.mn.org (Robert E. Brose II)
Subject: token ring pd
To: tcp-group@ucsd.edu
The ibmtoken packet driver REQUIRES ibm lan support. There is no
packet driver that talks directly to the token ring card.
Bob
------------------------------
End of TCP-Group Digest V93 #69
******************************
******************************