Date: Mon, 15 Mar 93 04:30:41 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 #71
To: tcp-group-digest
TCP-Group Digest Mon, 15 Mar 93 Volume 93 : Issue 71
Today's Topics:
CSMA/CD on radio ? (I see a way CD can be done)
tcp-group charter
tomcat.gsfc.nasa.gov to QRT
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: Mon, 15 Mar 93 09:03:06 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CSMA/CD on radio ? (I see a way CD can be done)
To: tcp-group@ucsd.edu
I have read Kurt Freiberger's and Mark Fraser's replies.
The "collision signal" idea is related to secondary channel idea
implemented in some modems (but I cannot say about any implementing it):
it is additional channel, much slower than primary, which can be used to
send some control or test information.
A duplex channel can be used for collision detect, too. Simplest way to
do it I see: need a "regenerator" retransmitting everything it receives
witch frequency change; every station sends using frequency f1, receives
on frequency f2, while regenerator sends on f2, receives on f1; station
listens while transitting and must verify data from the regenerator is
same as it sends, when it isn't it should stop transmission; regenerator
can detect carrier lost or invalid packets but it isn't necessary.
I have also read Charlie Greene's msg - his idea of use 2 frequencies
for link with any number of intermediate stations seems to be quite good
(but seems there are some mistakes in station names in his msg).
Note it requires regenerators to be addressable - a packet can contain
regenerator's callsign inside and only the addressed regenerator should
retransmit it (note both regenerators use same transmit frequency).
And: I don't feel to be wise enough to discuss every problem of packet
radio, just few random thoughts presented in hope they may be useful for
someone more wise... (even silly idea may be useful for "brainstorm"
style thinking, as a point to start for wise people). 73's, JT
Below included a message from Mark Fraser (had no CC: tcp-group).
Message-Id: <m0nX40Q-0000zVC@van-bc.wimsey.com>
Date: Thu, 11 Mar 93 23:18 PST
From: mfraser@wimsey.com (Mark Fraser)
Subject: Re: CSMA/CD on radio ? (I see a way CD can be done)
Newsgroups: local.tcp-group
In-Reply-To: <C3q0xw.Aux@wimsey.bc.ca>
Organization: Wimsey Information Services
The real problems are two receivers needed, two channels needed, and
the scarcity of channels almost anywehere in the spectrum.
Duplex (one send, one receive) channels are frequently ueesed, and can
be much more efficient than a simplex (everybody sends on same channel) but
still takes twice the bandwidth.
NO free lunch. An analysis of the traffic flow is worthwhile. For
some applications, most traffic is mobile inward, for others outward to
portable/mobile units. Others acan be unit to unit, between vehicles
or portables. The contention management scheme and the throughput
calculations are quite different for all variations in these flow patterns.
There are even ways in which a "polled" scheme can work; some have
prpposed and evaluated binary group polling "have u anything to send";
if 2 respond, the binary group polled on the next poll from the boss is
haalf as big, until just one is heard. This wording is relevant - as you
pointed out, one tx can capture a receiver, just by being closer to it.
Multiple access problems (channel access) aren't the only ones. What
about ARQ error control - error detection, followed by a request to resend
a packet (in which an error has beeen detected...). This can take place
a lot more efficiently in a duplex channel.
And the study goes on...
Regards
Mark Fraser
------------------------------
Date: 15 Mar 1993 23:01:06 -0500 (Mon)
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: tcp-group charter
To: tcp-group@ucsd.edu
I've said this before but ....
Why not regularly *post* the charters of tcp-group and the other lists to
remind us what topics the list actually serves. This would stop a lot of the
noise as folks would be continually reminded where they should post their
questions/ideas etc. Also we see subscribers on tcp-group posting because
they are simply *unaware* that other lists exist such as the excellant
<nos-bbs@hydra.carleton.ca> and many others. Some of you may be worried that
if we 'advertise' tcp-group to the great unwashed we will increase the noise
level again, but I feel that provided we advertise _all_ of the groups, people
will be able to more carefully choose which list they wish to post the
particular article to. When someone new subscribes to 'tcp-group' (or any of
them) they could by default, be sent a copy of the FAQ and the charter of the
group. I'm open to suggestions where each of these charters are posted as each
should have references to the other but not necessarily have a full desription
(was that clear?)
just an idea ...
Steve - ZL1BHD
------------------------------
Date: Sun, 14 Mar 93 19:27:44 UTC
From: clark@tomcat.gsfc.nasa.gov (Tom Clark -- W3IWI)
Subject: tomcat.gsfc.nasa.gov to QRT
To: tcp-group@ucsd.edu, amsat-bb@amsat.org
Hi Gang --
This note is sent to let you know that my tomcat.gsfc.nasa.gov will cease
to be available as an ftp file server (both on Internet and via the SLIP
port) in a few days. (AMSAT ANS bulletin about tomcat that was sent out a
few weeks ago should be considered null and void!).
In a couple of weeks I leave for a several month sabbatical as a Visiting
Professor at the Chalmers Institute in Goteborg, Sweden. I also will likely
be spending some time in Norway, Finland, Russia and Spitzbergen, so you
may see me on the air with SM6, LA, OH, UA3 and JW calls. [in JW I am
helping the Norweigans build a new 20M dish antenna, so there is a
possibility of an EME DXpedition!).
I would have started pulling the plug this weekend, but the big snowstorm
has the DC area paralyzed and its not easy to get into the office!
When I return in the summer, I will probably move tomcat physically to
a location where it can provide an Internet ENCAP gateway for the MD/DC
area. It is quite possible that it will provide a telnet function that
will provide RTCM-104 real-time GPS corrections for the east coast.
For the tcp/ip community, tomcat has been a "mirror" for the ucsd.edu
anonymous ftp archives so I'm sure it's loss won't be severe.
For the AMSAT community, tomcat has been the repository for a lot of
working materials, including the GIF files from all the cameras in orbit.
AMSAT has its own host amsat.org (physically on the UCSD LAN and tended
by Brian, WB6CYT and Paul, KB5MU). I hope it will soon acquire some more
disk space so it can serve as AMSAT's ftp file server.
Personally, I am already set up as either
tac@oso.chalmers.se
or w3iwi@amsat.org
and while I'm gone, these addresses are preferable to the "standard"
clark@tomcat.gsfc.nasa.gov, although the tomcat address will be "patched"
thru to Sweden also.
The W3IWI packet system will also go QRT at the same time. Hopefully, the
local arrangements we have made will make the transition fairly painless.
73, Tom
------------------------------
End of TCP-Group Digest V93 #71
******************************
******************************