| |
PA2AGA > HDDIG 24.03.00 02:34l 204 Lines 7861 Bytes #-9537 (0) @ EU
BID : HD_2000_82
Read: GUEST
Subj: HamDigitalDigest 2000/82
Path: DB0AAB<DB0PV<OE2XOM<OE5XBL<OE6XAR<OE3XPR<OM0PBM<OM0PBB<SR9ZAA<PI8JOP<
PI8ZAA<PI8GCB<PI8WFL<PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 000323/2127Z @:PI8VNW.#ZH2.NLD.EU #:59023 [HvHolland] FBB7.00g24 $:HD_200
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA31811 ; Thu, 23 Mar 00 21:13:52 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.70/7.5.3) with SMTP
id AA00018486 ; Thu, 23 Mar 2000 21:26:30 MET
Date: Thu, 23 Mar 00 21:25:05 MET
Message-Id: <hd_2000_82>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 2000/82
X-BBS-Msg-Type: B
Ham-Digital Digest Wed, 22 Mar 2000 Volume 2000 : Issue 82
Today's Topics:
May QEX digital voice article (3 msgs)
NOS (and derivatives) don't send FRMRs ?
Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives/ham-digital".
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.
Loop-Detect: Ham-Digital:2000/82
----------------------------------------------------------------------
Date: Sun, 19 Mar 2000 02:17:16 -0600
From: Brian <burke1@icss.net>
Subject: May QEX digital voice article
Dave Heil wrote:
> That's an outrageous statement, Brian, backed by ignorance of that which
> is possible.
>
> Dave 5H3US, K8MN
You can't back up that untruth by any statement or deed on my part. ;^)
>.
------------------------------
Date: Tue, 21 Mar 2000 22:26:58 -0600
From: "Steve Sampson" <ssampson@usa-site.net>
Subject: May QEX digital voice article
This is the basis of Christianity also...
"W6RCecilA" wrote
> You can't work someone if you can't hear them but it doesn't mean that
> they do not exist.
>.
------------------------------
Date: Tue, 21 Mar 2000 22:03:12 -0600
From: W6RCecilA <Cecil.A.Moore@IEEE.org>
Subject: May QEX digital voice article
Jeffrey Herman wrote:
> We're counting the QSOs; you can't work someone if you can't hear them.
You are not counting the QSOs, Jeff. You are counting the QSOs *that you
can hear*, a very subjective situation. The ratio of the number of CW QSOs
that you can hear to the number of SSB QSOs that you can hear is not
anywhere near the ratio of total CW QSOs to total SSB QSOs.
You can't work someone if you can't hear them but it doesn't mean that
they do not exist.
--
73, Cecil, W6RCA http://www.mindspring.com/~w6rca
>.
------------------------------
Date: Wed, 22 Mar 2000 10:35:00 GMT
From: nomail@rob.knoware.nl (Rob Janssen)
Subject: NOS (and derivatives) don't send FRMRs ?
Hank Oredson <horedson@att.net> wrote:
>> That is something that should be avoided... use a permanently available
>> gateway and/or combine it with the net/rom node.
>> (IP routing in the nodes, that is what you need)
>Hmmm ... think I have something different in mind.
>In the case of interest, all stations are nodes, and all route.
Then you can use plain AX.25 on the last hop. So your node network
internally uses NET/ROM and routes IP over it if it cannot be avoided, and
the end user stations use plain AX.25 UI or VC links to the nearest node.
>> When you don't do this, you will see old and forgotten nodes appear and
>> re-appear in your list for months! Believe me, I have tried it.
>Not sure how this occurs, other than some software bug.
>Computer clocks are quite accurate, and it is simple to avoid
>broadcasting long dead routes.
Clocks may be accurate but sysops aren't. I have included some commands
to sync clocks between nodes and I multicast the clock time as part of
a node info multicast packet, and I still see big differences in clock
time between nodes.
The problem with my implementation may have been that there were two
separate commands, one to load a table from disk (this was just the
standard "source" command) and one to save a table to disk at regular
intervals. This provided plenty of opportunity for the careless to
foul things up: remove the save command but leave the file on disk and
the source command that reads it, for example.
So the file data had to have some reliable "age" info, something that
the node in normal operation stores in a downcounter that is decremented
at regular intervals. Of course the counters don't decrement while the
file is on disk.
Over time I have learned that one should avoid any involvement of the
node sysop in accurate functioning of his node: either he does not care,
he does not want to study the matter and just carelessly copies a config
from a friend, or he thinks he understands it all and starts to modify
every line in the file to leave his mark on it.
The Flexnet people have understood this as well and have removed all
configurability... unfortunately the structure of the NET/NOS config
does not lend itself well to removing, because the items in the config
file often perform some "action" during startup. That is more difficult
to hardwire than just fixing a set of values.
So, I decided just to remove the function. Transmission of a few seconds
of node information at restart time (which normally occurs at intervals
of several months) really is no problem.
>> So, it is better to always start up "clean" and ask the neighbors what
>> nodes there are.
>Certainly not when a node is shut down for a few minutes (or even hours)
>of maintenance, which is the usual case here.
Why not?
>> But that can only work when you define a new protocol or the endpoints
>> agree that all traffic towards them is IP. The PID is not transported
>> in NET/ROM connections :-(
>Several possible solutions here, some involving simple changed to the
>NET/ROM protocol. G8BPQ did that already, so I'm not adverse to
>using an extra bit (or byte) in the L4 connect request and connect
>acknowledge to indicate "I encapsulate ip". Similar idea as the SABME ...
I was not aware that G8BPQ code had such an extension.
There are other extensions, by G8BPQ and others, but I cannot oversee
quickly if you could add such an extension and have compatible behaviour.
>> There will be not much difference anyway, unless you are using multi-hop
>> NET/ROM connections. With a single end-to-end connect the packets between
>> the nodes are datagrams anyway.
>If it's single hop, we don't use NET/ROM connections.
>There is only one station using ip that is a direct connect for me. All the
>rest are several to many (3-6) NET/ROM hops away. Big wide open spaces
>out here in the Western USA.
Of course I don't mean single AX.25 hop between the endpoints. The number
of hops at that level should not matter.
I mean the practice of using several back-to-back NET/ROM transport level
connections between te endpoints (by first connecting to some node, then
onwards to the endpoint)
What you need is: nodes that understand and route IP. Then you are only
involved with the connect to your local node, and it does not matter if
it routes your IP packets over NET/ROM or over plain AX.25 circuits or
datagrams. In a network of a large number of such nodes, IP packets can
be transported over a mixture of different methods. They usually won't
take 3-6 NET/ROM hops at a time, but it could be done.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
End of Ham-Digital Digest V2000 #82
******************************
You can send in your contribution to this digest by
sending an e-mail to: hd-group@pa2aga.ampr.org
or (via BBS-net) to: hdaga@pi8vnw.#zh2.nld.eu
Read previous mail | Read next mail
| |
