[nos-bbs] FTP wierd socket from domain.txt

[(Skip) K8RRA]

It probably is a bad sign when I reply to my own mail.
But this note *should* bring closure to this thread...

On Sat, 2007-05-26 at 21:50 -0400, (Skip) K8RRA wrote:
> On Sat, 2007-05-26 at 19:36 -0400, Jay Nugent wrote:
> > Greetings,
> > 
> > On Sat, 26 May 2007, (Skip) K8RRA wrote:
> > 
> > > My neighbor >>SNIP<< will have to go through
> > the whole resolve process over and over and over again. 
> Clarification?
No clarification to be had...
If there is anything important about this issue - it is that domain.txt
has the characteristic of (self?) destruction from unknown causes at
this time.  It is likely a program instability, and not very often an
occurrence.
> >>SNIP<<  So up your smtp timer
> > to wait longer before trying again.
> > 
> >    smtp timer 900      <--- 15 minutes (was probably set to 5 mins)
> Would you believe 1805 for a setting?  Something else *has* to be going
> on...
The above is good advise during trouble shooting because multiple
simultaneous SMTP links obfuscate the issue and make trace reading quite
difficult...  On our link over RF, it turns out that adjustable
parameters were at fault.  The issue manifest itself predominantly on VC
channels.  The cure was to slow down TCP/IP to allow AX.25 to heal
itself when encountering an RF "problem".  

Think of it this way: both AX.25 and TCP/IP protocols have broken link
detection and transmission retry schemes that are fairly similar.  When
TCP/IP is carried over Datagram (UI) option of AX.25 then the TCP/IP
scheme is the protocol in command.  When TCP/IP is carried over a AX.25
connection (I) option, then both protocols have schemes in play and when
TCP/IP is configured to be more aggressive than AX.25 the channel will
clutter up with retry packets and severely delay movement of source data
over the channel.

Jnos is what it is and the solution is to "slow down" TCP/IP error
detection and retry parameters to allow AX.25 to do it's job when TCP/IP
is encapsulated in AX.25 over (I) channel.  This practice may adversely
effect TCP/IP over (UI) link, but is the consequence of a "mixed"
environment of both (UI) and (I) over RF.  If the specification were
mine to write, I might like to "defeat" TCP/IP error detection and retry
when carried over (I) links, or at least detune selected parameters by
say 4X(?), however that is "pie-in-the-sky" and not todays reality.

This subject is now on my development list and will appear under the
subject of "tuning" performance of jnos parameters on the jnos wiki.
> > 

> >    But now that were're done with SMTP, back to FTP.  Which I'll answer in 
> > a seperate email.
> OK - good idea.
> You might want to wait until we have a chance to repair domain.txt and
> segmentation too?
After adjustment, FTP transferred a 100k ascii file with a minimal of
retries over a "busy" channel.  Problem solved...(?)

In isolating the cause of the original problem, I have perhaps found a
circumstance where jnose code is not stable.  This is not to disparage
Maiko or any programmer before him.  This is a suggestion to NOT try to
get the "last ounce" of performance from jnos installation because jnos
is not a race car.

The offending parameters existed at both ends of the link.  The solution
demanded adjustment for two jnos sites, not just one.  The parameter
mis-setting problems we had, presented themselves by erratic behavior in
using non-valid IP numbers, and leading to garbage in domain.txt file,
plus even more subtle problems not discussed here.  

It is my opinion that jnos has an internal processing logic problem that
manifests itself only under "stress".  At this time it is probably not
warranted to design a test bed and diagnostic approach to locate my
suspected problem.  As nos users it is probably enough that we be aware.
> > 
> >       --- Jay Nugent  WB8TKL
> 
> 
> 73
> de [George (Skip) VerDuin] K8RRA k
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de [George (Skip) VerDuin] K8RRA k