[nos-bbs] Looking for confirmation of performance

Tue Aug 8 18:35:25 EDT 2006

> ["George (Skip) VerDuin" <k8rra at ameritech.net> wrote]:

> > > Using "connect NET/ROM ALIAS" to link to the same station as above
> > > works, however "bye" does not clear the ax25 active connection table.
> >
> > Right.  It doesn't need to.
>
> It doesn't "need" to because:
>
> a) if a new user steps up he can reuse the already previously used
> but no-longer-in-use link?

Absolutely.  The "no-longer-in-use link" may actually be "in-use" by
another transport connection.  It is only "no-longer-in-use" according
to *this* user.

> b) Higher levels have no responsibility to cause lower levels to tear
> down and clean up active sockets?

Don't confuse a socket with a protocol layer connection.  The only
socket associated with the Net/Rom transport connection you have
described above is that which delivers data to/from the transport
layer to/from the application.  There is no socket associated with
the link layer connection because it is there only to support the
higher protocol layer and is not itself a direct conduit to the
application.

> I can accept the way it works if the way it works is the intent of
> network handling.  I do find it curious that lower levels must service
> upper levels quickly (the first packet SABM goes out in milliseconds)
> but have no need to clean up when done.

I make sure AX.25 circuits which exist only to service higher protocol
layers between "adjacent" devices *never* expire by disabling the check
(t3) timer entirely.  Why take time to set up and tear down a link layer
connection every time a packet carrying higher layer protocols needs to
be sent?

> I also find it maybe a little wasteful to be issuing packets when
> response will never be needed or processed.

Well, that's AX.25 for you.  :)  But all kidding aside, there is no
AX.25 "chatter" between adjacent devices unless you have a check (t3)
timer on, or are using FlexNet, which is a different story altogether
and beyond the scope of this discussion.

> > > Using "connect NET/ROM ALIAS" to link to a non-reachable node continues
> > > to try until "CTRL-T" terminates the attempt but it also does not clear
> > > the ax25 active connection table.
> >
> > Right.  It doesn't need to.
> >
> > > In both cases above, the transmitter continues to issue packets (not
> > > detail traced for this email) until maybe a timer or counter expires.
> >
> > Maybe the check (t3) timer or the retry (t1) timer/counter.
>
> It's clear that damaging "keep alive" during no activity is not wise
> beyond reasonable activity lulls for the sake of tearing down at end of
> use faster.

That's right!  Which is why the check (t3) timer should always be
disabled.  In programs I compile where the AX.25 layer itself is never
used as a direct path to applications, I actually save codespace by NOT
compiling AX.25 check (t3) timer code (and other related code which
pertains specifically to having direct "user" access to AX.25
interfaces).

> Redundancy timer is available to clear out "idle" connections -

Yes, it is, but they are intended to clear out connections to
applications.  The AX.25 "redundancy" timer in some versions of NOS
is actually misplaced.  The "redundancy" (or t4) timer is actually
(or should be) an *application* idle timer, not a protocol layer
timer.

> I just did not expect to see it used to clear out "terminated"
> connections...

It does in the AX.25 layer in JNOS because that is how it is
programmed, but really, there shouldn't be one there, or in
the Net/Rom transport layer for that matter either.  A t4 timer
should be in the application and set on a "per-user" basis...
again, this is beyond the scope of this discussion.

> > > I'm at jnos2.0d level and this is a request to validate my findings
> > > on 2.0d or 2.0e rev installations.
> > >
> > > If my node is "odd man out" then perhaps someone knows what my
> > > configuration error might be?
> >
> > I doubt you have a config error.  When you are using Net/Rom you
> > are now passing a Net/Rom network layer 3 and transport layer 4
> > over your AX.25 link layer 2 connection and you are now passing
> > the data for your application layer 7 (the JNOS mailbox) over
> > the Net/Rom transport layer 4 connection.  When you close down
> > the sockets on each end (i.e. the user disconnects from the
> > application) the Net/Rom transport layer 4 connection will be
> > torn down as well.
>
> Of course "torn down" has a different context than "allow to die
> naturally and rot away from dis-use".

Yes... which by definition must occur at a much higher (i.e.
application) layer rather than at a protocol layer.  The protocol
layer has no direct knowledge of the data it is carrying, so how
can this timer possibly be doing the right thing when it is executed
in in this layer of the network model?

> > In *this* case the Net/Rom transport link layer 4 connection is
> > handing data directly to the application sockets for this user's
> > "connection" to the application and the AX.25 link layer 2
> > connection may stay behind in order to handle multiple Net/Rom
> > transport layer 4 connections.
>
> My "training" is that each instantiation of use gets its own unique
> socket.  It seems that termination of upper level processes constitutes
> adequate reason to further terminate everything assembled specifically
> to support the higher level process.  This action would return the stack
> to it's pre-use structure.  Again - I will document the as-is if it is
> as-intended / I have no axe to grind by either approach.

Ok, let's talk processes.  Processes exist at the highest layer of
networking, i.e. at the applications.  Each new user-application
connection opens a new process.  And if that process spawns another
process (for instance, if a mailbox user gateways out of a mailbox to
another machine somewhere else) then when the first process terminates
it will signal the sub-processes to be terminated as well, and so on
and so on.

Now each new user-application connection (each new process) gets its
own unique socket number.  A socket is simply the assigned number of
a datapipe that is associated with both the application and the
delivering protocol.  Don't confuse the socket number of a user-
application connection in a machine with the "connections" of the
underlying protocols BETWEEN devices to actually move the data from
one end of the user-application connection to the other.  Transport
connections generally have no knowledge of any link connections
underneath which carry them and vice versa.  And only at the "service
access point" or point where the data is passed between the application
(i.e. the process) and the protocol layer which carries it is there a
socket number associated with it.

Remember also, by "application" I mean the "applications" at BOTH ends
of the user-application connection, i.e. the client *and* server ends.
There is a separate socket (and process) associated with each end of
the connection that delivers data to/from the protocol layer(s) which
carry that data to the "other" end of the connection.  Each "layer" of
the network has no legislated knowledge of the layers below or above
it.  Hence, the OSI model.

> > The same would also be true if you were using the TCP(/IP) protocol
> > as a user's connection to your application(s) directly under an AX.25
> > link layer 2 connection.  The same AX.25 link layer 2 connection may
> > handle multiple transport connections across it.
>
> Actually I've noticed TCP persists too - but did not include it into the
> test case for this email on the presumption of being a similar answer.
>
> THANKS FOR THE COUNCIL Barry...

Counsel maybe?  LOL  Actually, I need a life.  :)

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+