Date: Wed, 10 Mar 93 04:30:13 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 #66
To: tcp-group-digest
TCP-Group Digest Wed, 10 Mar 93 Volume 93 : Issue 66
Today's Topics:
advanced-packet list is open for discussion (2 msgs)
any lower version of nos
APRIL DDJ
CSMA/CD on radio ? (some random thoughts/ideas)
In-Reply-To: Re: hidden transmitter routing (3 msgs)
NOSIntro
PC-LAN cards -- ARRGH!
pmnos and mbox forwarding
repairs at the physical layer
RF Bits Where next?
TCP/IP -- more than just mild! (2 msgs)
TIPMAIL hog
Why do .lck files cause mail loops? (3 msgs)
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: Tue, 9 Mar 1993 11:55:57 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: advanced-packet list is open for discussion
To: tcp-group@ucsd.edu
The advanced-packet list, for discussion of the implementation of new
packet-radio protocols, is now open for discussion. You might want to move
some discussions that are currently on tcp-group over to advanced-packet.
If you would like to subscribe, send mail to LISTSERV@PIXAR.COM with
this line in the message body:
subscribe advanced-packet YOUR-FULL-NAME
I am still learning how to administer a list-server, so mail problems
to Bruce@Pixar.com .
Many Thanks
Bruce Perens KD6OTD
------------------------------
Date: Tue, 9 Mar 93 23:08:20 -0800
From: brian (Brian Kantor)
Subject: advanced-packet list is open for discussion
To: tcp-group
Now that Bruce has the advanced-packet list running, I can stop running
the advanced-packet list here, and since tcp-group no longer needs to
exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.
Any objections or comments?
- Brian
------------------------------
Date: Tue, 9 Mar 93 14:26:30 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: any lower version of nos
To: JT@zfja-gate.fuw.edu.pl, jsteinhu@nyx.cs.du.edu, tcp-group@ucsd.edu
On Tue, 9 Mar 93 09:22:50 PST, Jerzy Tarasiuk wrote:
[stuff deleted]
>Has anyone any thoughts/ideas/...etc. on this subject ?
>
>Where can get the TCP-IP code from Watterloo University ? 73's, JT
The TCP-IP stuff from Waterloo is available via anonymous ftp from
sunee.waterloo.edu in /pub as wattcp and winwattc (has some additional
windows code) ZIPPED files. If this site is a problem, it's mirrored
on a dozen or so more, just ask archie. Don't have archie? post a request
on the net and I'll help you find a site you can access.
The code is pretty complete and will show you what goes on with TCP-IP.
73
Marvin Match KA7TPH
------------------------------
Date: Tue, 9 Mar 93 16:45:05 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: APRIL DDJ
To: tcp-group@ucsd.edu
The April 93 issue of DDJ has an article on memory management, comparing
the efficiencies of Borland vs. MS compilers. It also points out the
differences in the way the two compilers manage memory. The article is
titled "Measuring Fragmentation". Also in this issue "Routing Algorithms
for Networking".
------------------------------
Date: Wed, 10 Mar 93 09:54:34 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CSMA/CD on radio ? (some random thoughts/ideas)
To: tcp-group@ucsd.edu
I saw some people are writing about CSMA/CD on radio. I know what it
means on Ethernet: transmitter circuit of Network Interface Card can
detect there is more than one card sending a time and asserts the CD
(Collision Detect) signal; it detects collision by measuring DC level
of signal (a node drains current from E. cable only when it sends and
value of the current is standarized, cable terminator resistance is
standarized, too, since can determine number of transmitting cards by
measuring DC voltage); the CD way is main limitation of cable segment
length (the 180m thin or 500m thick wire, by careful adjusting level
thresholds can extend them to 300/1000m, based on National Semicondu-
ctor's Application Note). It is easy on Ethernet: resistance of wire
is few times smaller than terminator resistance since voltage levels
are almost same regardless of distance. But radio it is not the case:
voltage level is reverse proportional to distance and can get signal
from other station 80-100 dB below own signal (unless use microwave
link and large parabollic antenna, but even then loss is too big).
A way CD can be done: send a "preamble" signal, then listen for some
time; if don't hear any other station, can start transmission. The
"listening time" must be large enough for radio signal to travel to
most distant station and back (worst case: we send preamble, it
reaches other station when it sends own preamble since it doen't hear
the our, but we can hear its preamble), seems need also invent a way
to prevent problems when two stations are near and they both send the
preamble in same time (possible solutions: put a station ident in the
preamble in some digital form, e.g. CW, and listen while key is off;
send few short signals, with some time between them, listening during
the time, and times are defined uniquely for every station).
Some disadvantages: such a preamble + listen takes time comparable to
short packet at higher baud rates (like 9600); note quick switching
transmitter on/off would result in noise sent to wide bandwidth since
must do it smoothly and use much more time, and listen time must be
large enough to allow signal travel to far station and back.
I suppose much more efficient can be central controller which would
send information to every station when it can start transmission
(e.g. send ONE packet informing every of several stations: you can
start sending after xxx milliseconds; a station in such a packet
would be identified by "handle" assigned by the controller after
initial contact). In a case a station is not ready to send when gets
a "time slot" it should inform controller about it (e.g by a flag in
last packet sent; such a flag can say one of following: "need small
time-slot, header+few data bytes only", "need large time-slot to send
nn kBytes", "will pause for nn cycles", "will not need time slot
before nn seconds (or ms)", "will request time slot when need") for
it to allow other stations to use the time. The controller should
also send a packet informing all stations "now is time to request
time slot" and a packet saying "now is time for new stations to try
get initial contact". The initial contact: station sends its callsign
and waits for controller's reply, the reply gives a "handle" for the
requesting station and station should then exchange few packets with
the controller to synchronize clocks, determine propagation delay -
the information will be necessary for efficient use of "request time
slot" function, to allow sending these requests by many stations in
short time without possibility of collision; measuring propagation
delays between stations may be useful, too, to allow the controller
to optimize time slot assignment for best channel utilization, note
two distant stations can send in some time - the requirement is
receiving stations will not get signal from many senders at same time
(doing such optimizations requires controller to know which stations
are to receive packets, not only which sends them). 73's, JT
------------------------------
Date: Tue, 9 Mar 93 09:31:43 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: In-Reply-To: Re: hidden transmitter routing
To: tcp-group@ucsd.edu
> Date: Tue, 9 Mar 93 0:08:49 HST
> From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
> To: jackb@mdd.comm.mot.com (Jack Brindle)
> Cc: tcp-group@ucsd.edu
> Subject: Re: hidden transmitter routing
> In-Reply-To: Your message of Mon, 8 Mar 93 10:08:34 PST
>
> At 56 kbps, one could even think about doing collision detection
> between packet transmissions assuming the maximum packet size is
> chosen to never exceed a quarter-second transmission time. I can see
> a modified collision-detecting KISS that doesn't clear a packet from
> the transmit queue until it sees the packet echo from the satellite
> between transmissions.
I think it's helpful to first consider the hidden transmitter
problem where we have it now, right on earth. I live in the
mountain zone and we have lots of mountains. Nodes are on these
hills that are 14,000 feet amsl and cover 10000 square miles of
our state. This node called ABQW and it has 9 routes and for
talking now no users. Each of the 9 nodes may be trying to reach
ABQW with a packet, but NONE OF THE 9 ROUTE NODES HEAR EACH OTHER.
If all 10 nodes can hear each other, there is no problem
since the tnc-2 has a dcd system that precludes transmitting if it
hears another node already transmitting. But since ABQW is the
only node that hears all 9 others the dcd function only works for
ABQW. In a real world this situation is collision city. The actual
baud rate drops from 1200 to 25 when the system is busy.
We can talk about back channels and duplex frequency use and
all this stuff but the actual practical solution is to design the
network so every node has exactly 1 (one) route. You do this in a
practical way by having 2 tnc-2's at every site with 2 radio
systems on seperate ham bands. Out here we like 220 and 70cm. A
network made this way with common 1200 baud tnc-2's will achieve
very close to 1200 baud true data transmission since there can
never be a collision!
>
> More exotic approaches might use some form of token-ring or
> time-multiplexing or a combination of the two. Not exactly sure how
> that would work though. Just thinking out loud folks. These problems
> have been bothering me for a while now and the current thread over
> reworking AX.25 caught my attention :-). Does anyone know of any
> papers that seriously analyse high-speed packet over high-orbit
> satellite links?
>
> Tony
Tony's thoughts out loud are good food for thought. There
must be a system that is smart. I think out loud that the
space bbs needs to have complete control over the frequency, and
have several modes. The bbs might open the frequency for check-in
at regular intervals. This is a free-for-all and with luck the bbs
will pick up several callers. For a much longer period the bbs is
in a data mode and will talk to only known stations. It will send
a packet addressed to station 1 and this allows that station to
send a packet to the bbs. Then the bbs address's the other users
and they respond in kind. When the bbs sends a *** done to a
station it is over for that station until another time.
Obviously more thought will get the system more efficient and
faster, but I believe in KISS (Keep It Simple Stupid).
73, karl
____________________________
| Internet IP 155.148.6.2 |
| Fido 1:305/111 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays |
|__________________________|
------------------------------
Date: Tue, 9 Mar 1993 14:12:39 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: In-Reply-To: Re: hidden transmitter routing
To: tcp-group@ucsd.edu
:"klarsen@mercury.arl.army.mil" writes,
> We can talk about back channels and duplex frequency use and
>all this stuff but the actual practical solution is to design the
>network so every node has exactly 1 (one) route. You do this in a
>practical way by having 2 tnc-2's at every site with 2 radio
>systems on seperate ham bands. Out here we like 220 and 70cm. A
>network made this way with common 1200 baud tnc-2's will achieve
>very close to 1200 baud true data transmission since there can
>never be a collision!
Let's restate this for those who may have missed Karl's point, or just
because I think it's important enough to merit repetition.
What we have here could be an instance of true CSMA/CD, where "CD" applies
because everybody's listening even while they're transmitting. This
requires ALL stations to be full duplex. This is easiest to do
crossband since it removes the need for cavities. One station, in this
case the one on a big mountain, is a repeater; the others don't repeat.
A somewhat less efficient scheme obtains if the end systems don't run
full duplex but the repeater does. This is CSMA. It loses efficiency
because two stations who "double" so close in time that they don't know
it will complete their transmissions without backing off. In practice,
the scheme outlined above may be just CSMA and not CD because tnc-2's
probably aren't smart enough to recognize that their own transmissions
aren't being clobbered. CSMA can work with one radio and one TNC at
each end site if the single-band dual-frequency repeater has a cavity.
The delta in efficiency between CSMA/CD and CSMA is caused by the
keyup time and propagation delays, which leave a window in which
stations can double. Both schemes are far, far more efficient than
Aloha, which is what you have when everyone's hidden. (The original
Alohanet was, like this, on a big mountain with lots of users who
couldn't hear each other. Of course it was in Hawaii, hence the name,
and around 1971, hence hams seem to think of it as modern.)
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.
fred k1io
------------------------------
Date: Tue, 9 Mar 93 13:46:27 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: In-Reply-To: Re: hidden transmitter routing
To: tcp-group@ucsd.edu
> Date: Tue, 9 Mar 93 14:19:41 EST
> From: "k1io, FN42jk 09-Mar-1993 1412" <goldstein@carafe.enet.dec.com>
> To: klarsen@mercury.arl.army.mil
> Cc: smtp@"tcp-group@ucsd.edu".bb.dec.com
> Subject: RE: In-Reply-To: Re: hidden transmitter routing
>
> :"klarsen@mercury.arl.army.mil" writes,
>
> > We can talk about back channels and duplex frequency use and
> >all this stuff but the actual practical solution is to design the
> >network so every node has exactly 1 (one) route. You do this in a
> >practical way by having 2 tnc-2's at every site with 2 radio
> >systems on seperate ham bands. Out here we like 220 and 70cm. A
> >network made this way with common 1200 baud tnc-2's will achieve
> >very close to 1200 baud true data transmission since there can
> >never be a collision!
>
> Let's restate this for those who may have missed Karl's point, or just
> because I think it's important enough to merit repetition.
>
> What we have here could be an instance of true CSMA/CD, where "CD" applies
My problem I hate to admit Fred, is that I don't understand
what CSMA/CD means and so I'm not sure your nice re-inforcement of
my message is really that...hi
> because everybody's listening even while they're transmitting. This
> requires ALL stations to be full duplex. This is easiest to do
> crossband since it removes the need for cavities. One station,
in this
> case the one on a big mountain, is a repeater; the others don't repeat.
What your talking about here Fred is a "Regenerator Node"
that requires a rf duplexer of good quality. We have one of these
running in Tucson, AZ and it's been successful.
>
> A somewhat less efficient scheme obtains if the end systems don't run
> full duplex but the repeater does. This is CSMA. It loses efficiency
OK that defines CSMA.
> because two stations who "double" so close in time that they don't know
> it will complete their transmissions without backing off. In practice,
> the scheme outlined above may be just CSMA and not CD because tnc-2's
> probably aren't smart enough to recognize that their own transmissions
> aren't being clobbered. CSMA can work with one radio and one TNC at
> each end site if the single-band dual-frequency repeater has a cavity.
>
> The delta in efficiency between CSMA/CD and CSMA is caused by the
> keyup time and propagation delays, which leave a window in which
> stations can double. Both schemes are far, far more efficient than
> Aloha, which is what you have when everyone's hidden. (The original
I have all the IEEE papers on the Aloha experiment Fred and
they should be REQUIRED reading before anyone can talk about
hidden transmitters. You should also have the messages between
myself and N7OO as we discussed what made a good packet network.
> Alohanet was, like this, on a big mountain with lots of users who
> couldn't hear each other. Of course it was in Hawaii, hence the name,
> and around 1971, hence hams seem to think of it as modern.)
>
> 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.
> fred k1io
Fred I used the 2 band approach because it is cheaper than a
single band and expensive duplexer. We are trying to get our
network to use this approach but funds are limited and we are not
there yet. Also I feel in the earth to space game some form of
smarts can be helpful. But rather than talk about it I will get
the necessary info and do a study. I have an up-coming trip to
europe and with nothing to do evenings it will be a good
project...
73, karl
____________________________
| Internet IP 155.148.6.2 |
| Fido 1:305/111 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays |
|__________________________|
------------------------------
Date: Tue, 9 Mar 93 10:58:24 -0800
From: brian (Brian Kantor)
Subject: NOSIntro
To: tcp-group
Path: network.ucsd.edu!news.service.uci.edu!cerritos.edu!arizona.edu!arizona!noao!ncar!gatech!howland.reston.ans.net!agate!iat.holonet.net!jchesner
Newsgroups: rec.radio.amateur.misc
Subject: NOSintro Book Available
Message-ID: <C3H2os.F6n@iat.holonet.net>
From: JCHESNER@HOLONET.NET
Date: 6 Mar 93 14:53:12 GMT
Sender: usenet@iat.holonet.net (USENET News System)
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Originator: jchesner@orac.holonet.net
Nntp-Posting-Host: holonet.holonet.net
Lines: 50
CAPRA - the Chicago Area Packet Radio Association has arranged to
obtain a supply of Ian Wade, G3NRW's new TCP/IP primer -
"NOSintro." Reviews of this book have been quite good.
This 356 page book is a hands-on tutorial with documentation
regarding TCP/IP and NOS software version of this international
standard as implemented for use with amateur packet radio
operations.
An earlier posting listed all of the 35 chapters of the book
which outline the basics and more advanced topics of TCP/IP;
there are 6 Appendices with additional reference materials and
information. The book has over 80 detailed diagrams with
"countless examples of commands and screen displays".
We expect to receive the books and mail them prior to the end of
March, 1993. In the event that this is not possible due to
unforseen circumstances, we will notify you if we expect delays
beyond April 15, 1993.
The books will be shipped via U.S. Postal Service's 2nd Day
Priority Mail service upon receipt here in suburban Chicago.
Ian Wade, the author, has given us a discount for our quantity
purchase. The cost to you will be $22.50 which is slightly under
the total cost which you would have were ordering directly from
the publisher in the U.K.
This is NOT a money making undertaking on the part of our group.
Many of us are active on TCP/IP and feel that this is a way to
increase the awareness of and technical expertise of others who
may be interested in or who are currently using the protocol in
amateur radio circles.
Send your complete mailing address, a telephone number at which
you can be reached should there be a problem, and a check/money
order made out to CAPRA in the amount of $22.50. Mail it to:
CAPRA - Chicago Area Packet Radio Association
Post Office Box 8251
Rolling Meadows, Illinois 60008
Please - no requests for information, orders, etc., via amateur
packet radio resources.
73 de Jim, N9GBH
CAPRA - Vice President
jchesner@holonet.net 70040.125@compuserve.com
(708) 253-0046 in Mt. Prospect, Illinois (NW Suburban Chicago)
------------------------------
Date: Fri, 05 Mar 93 22:54:11 MET
From: PA2HBN%PI8VNW@pa2aga.ampr.org
Subject: PC-LAN cards -- ARRGH!
To: TCPAGA@pa2aga.ampr.org
Mike, nowlin@ksuvxb.kent.edu reported a problem on the Clarkson NETBIOS
packet driver.
I experienced the same problem, which I traced down to a static declaration
of the receivers address at the receiving side.
With help of the source code (incomplete, I missed some include files), I
was able to trace the problem and patched the packet driver to use the
address as given on the commandline.
The following shows the DOS-COMPARE output, with NB.COM as the original
driver and NB_HBN.COM as the patched version of the driver.
These differences can be applied to the NB.COM file by means of the
DOS DEBUG program.
(I will try to send a UUENCODED driver to Mike next week by e-mail).
Comparing NB.COM and NB_HBN.COM...
Compare error at OFFSET 10B1
file1 = B8
file2 = A1
Compare error at OFFSET 10B2
file1 = C4
file2 = 19
Compare error at OFFSET 10B3
file1 = C3
file2 = 9
Compare error at OFFSET 10B5
file1 = B8
file2 = A1
Compare error at OFFSET 10B6
file1 = CC
file2 = 1B
Compare error at OFFSET 10B7
file1 = C2
file2 = 9
Hans Boon, pa2hbn,
e-mail: boon@hsacsd.signaal.nl
-----------------------------------------------------------------------------
Hans, pa2hbn IP: pa2hbn@pa2hbn: [44.137.46.12] ###
ax25: pa2hbn@pi8daz.nld.eu ###
smtp: pa2hbn@pi8vrz ###
-----------------------------------------------------------------------------
PLEASE reply to the list, NOT to the From: address
because this mail is sent through a one-way gateway!
------------------------------
Date: Tue, 9 Mar 93 07:09:25 EST
From: RWAUSTIN@ATLVM1.VNET.IBM.COM
Subject: pmnos and mbox forwarding
To: TCP-Group@UCSD.Edu
I have been unable to get the mbox forwarding to work. If I create a note
and address as: kk4l%kk4l@wa4bro to send a msg as listed, the system will
send me 'unknow host' when smtp kicks off. according to the smtp list the
host is 'wa4bro' as it shud be. There is no 'wa4bro' in my domain.txt file,
and the rewrite has *@wa4bro* wa4bro as the entry. there is a forward.bbs
file that has the entries for forwarding.
any ideas for me to try? Why would I get an 'unknow host' from smtp
when it kicks off? I thought if there were no entries in the domain file
it would just create a host.txt file and continue from there.
Boy when you think you have it down pat, something has to show you different
Thanks,
73,
=> Bob - N4CLH @ WA4BRO.ATL.GA.USA.NA
=> amprnet - 44.36.0.120 (n4clh.ampr.org) Atlanta, GA.
=> internet - rwaustin@atlvm1.vnet.ibm.com
------------------------------
Date: Wed, 10 Mar 1993 12:03:51 +1300
From: Steve_Wright@kcbbs.gen.nz (Steve Wright)
Subject: repairs at the physical layer
To: tcp-group@ucsd.edu
>From: jackb@mdd.comm.mot.com (Jack Brindle)
>Subject: hidden transmitter routing
Message-Id: <9303092305.AA06616@kcbbs.gen.nz>
Date: 9 Mar 93 23:05:40 EST (Tue)
>
>All of these problems could be resolved by going to a central controller with
>full duplex operation, and full duplex local node operations. The next best
>thing
>is a full duplex central controller with half duplex local operation.
Great! but how to do this in the 70cm band without wiping out many, many
frequencies. This is the only band that 9600 baud gear is commercially
available, unless you're advocating 1200 baud (shudder.)
The only ways I can see is either use spread-spectrum multiple access at 38
or 64Kbit, or use individual gunnplexor modules for each user. Lotsa money
for a packeTen switch (or five!) but the microwave units are cheap! Would be
able to run 1MBit without much problem. Wouldn't this go well ....The US hams
(most of you?) shoud be able to get a STA to run a meg on 10 GHz.
over to you.
Steve - ZL1BHD
------------------------------
Date: 9 Mar 93 18:39:00 PST
From: "39A::MUSCHINSKE" <MUSCHINSKE%39A.decnet@scfb.chinalake.navy.mil>
Subject: RF Bits Where next?
To: "TCP-GROUP" <TCP-GROUP@UCSD.EDU>
Increasing the bandwidth of our RF bits depends on a number of
factors. Some factors we can control and others we can't. We have
a regulatory environment we can influence but not control. We
cannot control the direction of RF technology, but we can benefit
from timely application of new technology. What we can control to
some extent is the implementation of our networks and their
affordability. Despite all of these factors, we need to increase
the speed of our networks.
The FCC in its infinite wisdom has strictly restricted the
implementation of over-the-air data transmission. Like it or not,
AX.25 is the bottom line mode right now. Our ability to do code
division spread spectrum is similarly limited. This needs to be
changed. It will probably take some STAs, lobbying and some kind
of nod to FCC monitoring needs.
The other part of the regulatory environment is frequency
coordination. We will have to fight for frequency allocations.
9600 baud two meter repeaters are feasable in rural areas, but not
in urban areas. In some areas of the country, parts of our bands
are not available (440, 902, 2450 MHz). Areas with the most packet
users have the most competition for frequencies.
Keeping these environmental facts in mind, we can more on to the
actual radio requirements. Design of the radio is a tight tradeoff
between bandwidth, frequency, functionality and cost. For the rest
of the discussion I will leave out HF systems (TCP/IP at 300 baud
is for masochists).
OK, what's the best radio? This is a multiple choice question with
multiple right answers and multiple wrong answers. A 1200/9600
baud system at two meters is probably a good idea, at 24 GHz it is
probably a bad idea. A 10 Mb 10 GHz system is a good idea, but how
many can you afford? What I'm leading up to is: What you use
depends on what you want to do.
First some basic ground rules: 1. You can't get really high speeds
below 450 MHz (legal bandwidth restrictions). 2. KISS (Keep It
Silicon Stupid!) this means below 2.5 GHz. (GaAs is low noise, GaAs
is high performance... GaAs is ex$pen$ive!) 3. 10/24 GHz
gunnplexers are a special case with their own problems and
advantages; better discussed by others, elsewhere. 4. The bulk of
users will remain on 2 meter 1200 baud AFSK packet for the next 5
to 10 years.
Most user uplinks will be multiple access 1200 to 19.2k baud (56k?)
on frequencies between 50 and 450 MHz. This is based simply on
rule 4 and cost. Of course, power users will want faster systems
:-). Six meters is a tradeoff between antenna gain and transmit
power with TVI thrown in to make things interesting. Two meters
will continue to be the most popular band. Hopefully radio
manufacturers will build in ports for 9600 baud plug-n-play. 1.25
meters faces a spectrum crunch in urban areas. It will probably be
used to add one more port to a node stack. 70 cm will probably
become the prime band for user uplinks. It offers a good trade
between price and performance.
A good place for high speed linking is in the 902-2500 MHz bands.
902 is an interesting band because it could allow a lot of use of
devices developed for cellular. It allows a good trade of antenna
size, transmitter power and stable oscillators. Difficulties are
vehicle monitoring in urban areas and the development of Part 15
spread spectrum systems in the band. 1300 MHz is a good band. It
is low enough in frequency to keep designs fairly simple, costs low
and losses low. It is high enough to allow small antennas with
enough directivity and gain to permit frequency reuse. The only
problem is that the band is starting to fill up. 2450 MHz is the
most wide open band. It has the greatest potential for wideband
data transmission. The band pushes the limits of silicon RF device
technology. The trade is expense and complexity for performance.
Where does this discussion lead? To the beginnings of a RF network
concept. The *minimum* network building block would be:
____________ ______________ ____________
duplex | | | | | | duplex
<----->| RF Modem |<---->| Node |<---->| RF Modem |<----->
High | | | Controller | | | High
Speed |__________| | | |__________| Speed
Data |____________| Data
Link | Link
|
--------------
<-------->| User |<-------->
| Access |
<-------->| RF Modem |<-------->
|____________|
This would replace the current high level single node or node
stack. This can be expanded to more links and more user access
nodes. The node controller will have to be a lot smarter than the
current Netrom stack. The question is how to make this attractive
enough to replace the current node system. The price must be low
enough that the added capability is worthwhile.
None of the equipment in the diagram really exists today. The
development of these pieces is what I am trying to stimulate with
this discussion. Please post your comments. I will even accept
well reasoned flames! :->
Please send follow-ups to the advanced-packet list. The remainder of my
ruminations will appear there.
73, Erich KA6AMD @ WA6YBN.#SOCA.CA.USA.NA
Internet: muschinske%39a.decnet@scfb.chinalake.navy.mil
------------------------------
Date: Mon, 8 Mar 93 14:19:58 -0500
From: grebus@isis1.bxb.dec.com (Gary Grebus)
Subject: TCP/IP -- more than just mild!
To: mg@bds.bds.com
But not extending TCP/IP to the end node makes it that much harder to
provide friendly, GUI-style interfaces. Part of the reason TCP/IP gets the
techno-weanie rap is that most of the implementations have a
character-cell/command-line user interface. It's much easier to do
true client-server style services if you have a single application
protocol to deal with.
What is needed are services that allow the TCP/IP network to be much
more self-configuring and automatically managed. Ideally, all I
should need to know as an end user is the callsign of my local service
node.
/gary
>Date: Sat, 6 Mar 93 04:54:47 -0500
>From: mg@bds.bds.com (Mike
Gallaher)
>Can't argue with that. However, we can still build networks based on
>TCP/IP without requiring that all the end users run it themselves.
>
>After all, you don't have to put NETROM in your TNC to use the NETROM
>network. We need only provide "service access points" that AX.25
>users can connect to. From there, they can telnet to other sites on
>the network, download files, look up callbook entries, etc. JNOS is a
>good example of such a service node.
>
>To these AX.25 end users, the network looks essentially like a BBS and
>NETROM node. They don't have to know that the nodes are connected by
>TCP/IP, but it will hardly be a secret. As they become more
>sophisticated, some of them may then want to run TCP/IP on their own
>machines and truly be part of the network....
------------------------------
Date: Tue, 9 Mar 93 15:11:29 EST
From: Mike Gallaher <mg@bds.bds.com>
Subject: TCP/IP -- more than just mild!
To: grebus@isis1.bxb.dec.com (Gary Grebus)
> But not extending TCP/IP to the end node makes it that much harder to
> provide friendly, GUI-style interfaces.
Nothing prevents anyone who is capable from routing IP datagrams
through the service host. The point is that even if you don't
run IP yourself, you can still use some of the network services.
GUI clients don't have to be TCP-based, either, though they're
certainly more flexible if they are. In any case, the end users
aren't any worse off with such an IP-based network than they are
now with NETROM, which is surprisingly difficult for some of them
to accept!
------------------------------
Date: Tue, 9 Mar 93 11:11:42 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: TIPMAIL hog
To: nos-bbs@hydra.carleton.CA
Jerry,
I fixed the problem that you mentioned and changed the way I did
it somewhat. ALL changes are now in tipmail.c. Add the following
function to tipmail.c This integrates all of the changes into tipmail.c.
No changes need be made elsewhere. Notice that the check for len_p is
now >1 rather than 0. This seems to solve the problem you experienced
in tip mail going into a loop. I could NOT duplicate this in my terminal
test setup but my internal modem also did this. I also check for loss of
carrier detect, so that data is not driven into a dropped modem. The
modem is in command mode at this point and stray data could cause problems.
Just a precaution, I have not had problems with this.
The stop of the idle timer CAN be done but it would be done in the
higher level application (mailbox) around things that take a long time.
I would not want to allow the user to disable it because it would defeat
the purpose of it being there to begin with. A better approach - that I
implemented is to reset it on output as well as input. The updated file
that I am putting at WG7J has all of these changes and you should no
longer experience timeouts as long as something is happening - in or
out within the timeout period.
Here is the new function in tipmail.c - all asy_send calls in tipmail.c
are changed to call this function. Note that the number of parameters
has changed. No changes to i8250, bmutil etc. Disregard any previous
changes.
Pickup tipmail.zip in the WG7J incoming to get all of the changes.
/* Send a message on the specified serial line
Wait for queue to empty - for slow serial
lines where data flow control is desired
Eliminates large queue - I.E. memory hogging
Stops data from flowing if CD is lost */
static int
asy_send_wait(dev,modem,bp)
int dev;
int modem;
struct mbuf *bp;
{
if (carrier_detect(dev) || !modem) {
asy_send(dev,bp);
while (len_p((struct mbuf*)&Asy[dev].sndq)>1
&& (carrier_detect(dev) || !modem)){
pwait(NULL);
}
} else {
free_p(bp);
}
return 0;
}
Please let me know if you experience any problems with this. I am testing
it here and if all looks good this should go into the next release.
Doug
------------------------------
Date: Tue, 9 Mar 1993 15:27:23 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: Why do .lck files cause mail loops?
To: tcp-group@ucsd.edu
My gri 2.0m system got into a mail loop apparently because it'd crashed
with /nos/spool/mail/bob.lck in place and I didn't automatically remove
this lock at boot time. Now my autoexec.bat reads (in part)
del tmp*.$$$ > nul
cd \nos\spool\mqueue
del *.lck > nul
cd \nos\spool\mail
del *.lck > nul
cd \nos\spool\news
del history.lck > nul
cd \nos\spool\mail\ampr
del *.lck > nul
cd \nos
del tmp*.$$$ > nul
Are there any other locks I need to clean up at boot time? Why would the
presence of a lock file cause a mail loop?
73, Bob, ke9yq
------------------------------
Date: Tue, 9 Mar 93 16:27:17 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Why do .lck files cause mail loops?
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
> Are there any other locks I need to clean up at boot time? Why would the
If you use NNTP to retrieve Usenet news, you can have lock files in
any of the news subdirectories. There is a zaplocks utility that
comes with the expiry program which will delete all lock files at and
below a directory branch. It's somewhere on ucsd as expiry.zip.
Tony
------------------------------
Date: Wed, 10 Mar 93 09:33:16 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Why do .lck files cause mail loops?
To: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
> Message-Id: <9303092128.AA07514@ucsd.edu>
> Date: Tue, 9 Mar 1993 15:27:23 -0600
>
> My gri 2.0m system got into a mail loop apparently because it'd crashed
> with /nos/spool/mail/bob.lck in place and I didn't automatically remove
NOS cannot remove it because of possibility you have multitasking and
another program has set the lock to prevent NOS access to a mailbox.
Reason of mail loop is: NOS sees mail to be sent in /spool/mqueue and
starts SMTP client session (to itself if it is local mail); when it
sees incoming SMTP session it accepts mail and attempts to deliver it
but it fails because mailbox is locked; then it stores the mail in
/spool/mqueue (note it doesn't check the mail is sent by it in another
process, and for mail from remote node it MUST accept it this way or
mail would need to be retransmitted later). Possible ways to fix it:
1. use "smtp mode queue" and incoming mail will be put in /spool/rqueue,
then external program may decide to move it either to /spool/mqueue
(when it is mail to another node) or to recipient's mailbox in
/spool/mail (if it is mail to local recipient) - the external program
can do nothing (eventually display warning) if the mailbox is locked.
2. change SMTP server code in NOS to detect mail is sent internally
(both server and client are on same node) and then in case of mailbox
busy return error (group 4xx = temporary problem). 73's, JT
------------------------------
End of TCP-Group Digest V93 #66
******************************
******************************