[nos-bbs] Looking for confirmation of performance

[George (Skip) VerDuin]

Interesting Barry...

On Tue, 2006-08-08 at 15:30 -0400, Barry Siegfried wrote:

> ["George (Skip) VerDuin" <k8rra at ameritech.net> wrote]:
> 
> > My node is acting in an non-clearing way.
> >SNIP<
> 
> > 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 user steps up he can reuse the already previously used
but no-longer-in-use link?
b) Higher levels have no responsibility to cause lower levels to tear
down and clean up active sockets?

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 also find it maybe a little wasteful to be issuing packets when
response will never be needed or processed.

> 
> > 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.
Redundancy timer is available to clear out "idle" connections - I just
did not expect to see it used to clear out "terminated" connections...

> 
> > 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".

>   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.

> 
> 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...

> 
> 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 |
> +----------+----------------------------+
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs


73
de Skip k8rra k


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.tapr.org/pipermail/nos-bbs/attachments/20060808/a684233c/attachment.htm