Date: Mon, 20 Dec 93 04:30:05 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 #328
To: tcp-group-digest
TCP-Group Digest Mon, 20 Dec 93 Volume 93 : Issue 328
Today's Topics:
Dealing with multiple ports...
KA9Q NOS in an OS/2 DOS Box?
Networks (2 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: Mon, 20 Dec 93 01:54:37 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: Dealing with multiple ports...
To: tcp-group@ucsd.edu
This gateway (uugate) now has multiple ports by which a TCP/IP users
may connect. How does one make sure packets get routed to the correct port?
Is this something that one would need ARP to handle?
<Clint>
------------------------------
Date: Sun, 19 Dec 93 21:31:21 CST
From: kf5mg@kf5mg.ampr.org
Subject: KA9Q NOS in an OS/2 DOS Box?
To: tcp-group@ucsd.edu
Is anyone running KA9Q's latest version of NOS in an OS/2 DOS box? JNOS runs
fine, but NOS keeps crashing the DOS box after a couple of minutes of
operating. I suspect that it's a problem with the Virtual Screen managment
code. Has anyone else had this problem. Thanks.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: Sun, 19 Dec 1993 09:00:50 -0700 (MST)
From: Klarsen <klarsen@acca.nmsu.edu>
Subject: networks
To: tcp-group@ucsd.edu
Well Tim seems to have mis-read my previous message due, no doubt
to the massive amount of beer consumed at the conclusion of finals. I said
the 3 frequencies I have at my home have no hidden transmitters. This is
true because on 445.1 there is only 1 node I hear and that is #elp. I hear
#elp and my dcd system assures we almost never xmit at the same time ( I
use the standard 100 msec delay and 64/256 tries statistical sample). It
IS true that #elp has hidden transmitters...
On 145.07 there are 5 routes on my g8bpq switch. This is bad but
not too bad since 4 of the routes go to users that go no farther. On these
4 routes there are hardly ever a collision because everyone hears every
one. The 5th route is to the node CAB. CAB has 5 routes, 4 of which are
local to Cruces and I think they hear each other. The 5th route is to SVC
in Silver City and I am a hidden xmit to SVC and visa versa. But my node
at home has no hidden xmitters.
On 223.4 there is only 1 route on my home node CRUCES. So I must
have only ELP2 to listen to and my dcd works fine. So no hidden Xmitters
here either. I contend that my node CRUCES has no hidden xmitters to
contend with and thus has no collisions except when the statistical 64/256
fails and 2 things exmitt together...
Away from CRUCES node the other nodes do have collisions. The
solution to this problem is time and money. More TNC's or Data Engines
or...and some smart design work. Today I discovered I need another 2 meter
frequency at my home. 145.07 is so busy with Tim's excellent internet
gateway that on weekends the frequency just dies from too many packets! So
I will explore putting on something on 147.96 or like that for users that
can hear me on my 14 element beam at 50 feet can reach the bbs without too
much other traffic. This is like the system in Utah, when the traffic gets
too high use another frequency that is netted to ALL the other frequencies
via a switch like the g8bpq.
Happy Holidays to you all
-karl
------------------------------
Date: Sun, 19 Dec 1993 11:22:26 -0600 (CST)
From: ssampson@sabea-oc.af.mil (Steve Sampson)
Subject: Networks
To: TCP-Group@UCSD.Edu
> Any situation where this arises blows to hell the
> collision avoidance mechanisms built into the protocols that we
> use since there is NO way one can arbitrate a simplex channel
> (under current protocols) where there are hidden terminals.
> Most of the congestion, it could be argued, occurs at the
> user-interface level on some 1200 baud channel. There is the
> tendancy to "put up another node" to "help" things out.
I seem to be in a minority, but I see beam antennas (directed beams)
as beneficial to UHF as it is to microwave. Too often I see "network"
nodes with Omni antennas. This is both wasteful of energy, and creates
interference. While we can get Omni microwave antennas cheaper than
parabolic reflectors, no one does it that way (power costs too much, and
it can be better used directively). The power needs to be directed toward
the intended target. Trying to take this logic down to UHF creates intense
argument. The fact is, power is cheap, so we pipe 50 Watts into an Omni and
splatter the whole area, while only -100 dBm of that gets to the target :-)
The JTIDS system uses Omni antennas (well one horn on the nose and one on
the tail) but they have the advantage of time and frequency spread-spectrum
techniques. That may be a solution for hams also (one or the other since we
can't do both hopping and direct-sequence).
Most of the mindset is currently in traditional radio, but we need to look
at the spread-spectrum products. I'd like to know where the rules changes
stand concerning digital modes. There was great fan-fare this summer with
the HF rules changes, but somewhere it got dropped in priority. Where are
we at with that? If we could use these Ethernet spread-spectrum products
in amateur radio, this would be superior to anything we could design.
> In the meetings and discussions a somewhat unfortunate truth has
> been observed: It is hazardous to talk about networking in the
> presense of those who are unfamiliar with its basic truths.
I'm surprised you actually had a forum. I think most hams understand
today the concept of user-nodes and network-nodes. The terminology
should be directed at the purpose of the node, and "backbone" doesn't
connotate "don't use it directly", as much as some other term like
"network" does. The more you hide the network, I think the better it
will be. Hams are curious and like to try and figure out each link
in the network; usually by connecting to them. Publish this information,
and let them know how their user-node fits into the big picture, let
them know how sophisticated it is. But on the air, just hide everything.
In the Net/Rom sense, don't list the network nodes in the table. For
Rose it's much easier to hide because if you leave out the Heard and
Users routines, you can't visualize it anyway. I think a JNOS type
interface is what the user needs. From here they can email, telnet, and
FTP across the network. Import the BBS junk and have another port on
another frequency that is BBS user-access only. Here you have one machine,
two or more ports, and restricted access to features based on port.
> One more thing: If you are thinking about putting up a network,
> do EVERYTHING you can to avoid putting up a "single-frequency"
> network. The debacle on 145.01 is a classic example of this.
This has probably chased more potential hams away than anything the
ARRL does. Once they see 145.01, the money get's spent on something
more worthwhile. It is "CB" mentality. That is, there's already
a bunch of users, nodes, and jammers on frequency, but since that's
where the action is - I'm a-gonna put up my node too 10-4! I think
that 145.01 should be the national APRS frequency, and that will
quickly chase the nodes away to where they should be anyway.
> Finally, it should be noted that these are first steps in the
> upgrading of the network around the state.
I think you guys are solving problems, and have the best goals as to
the big picture.
--
Steve
------------------------------
End of TCP-Group Digest V93 #328
******************************
******************************