using a mac with linux and filepro

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Monday, June 18, 2007 2:57 PM
Subject: Re: using a mac with linux and filepro


> On Sat, Jun 16, 2007 at 03:26:17AM -0400, Fairlight wrote:
>> Now one thing I noticed was that certain protocols are REALLY dodgy about
>> this.  I noticed ssh in particular, if I actually lost sync, I could have
>> connections up to IRC or whatever, and as long as I recovered sync by the
>> end of the 2min timeout window on a connection, I regained that
>> connection for most TCP connections.  SSH, however, -never- survived a
>> DSL desync.  If that route goes away, *poof*, you are -gone-.  This is
>> both PuTTY and openssh.  Doesn't matter which.  Any versions...I've run
>> into it across more than a few versions of each.
>
> Keepalives.
>
> As long as your workstation maintains the same address, PuTTY/SSH will
> survive the intervening link going away.
>
> Now, if you unplug the ethernet cable, XP will dump the interface, and
> *that* will kill your session, but as long as the application's (and
> the server's) keepalives are disabled, then the session will survive
> anything except an IP address change, in my experience.

Thats why I like the approach in SCO's stock telnet better than either 
facetwin (no keepalives anywhere) or putty/openssh (simple 
keepalives/heartbeat from server or client or both)

The stock sco telnet does no keepalives at all for 2 hours.
Then sends a telnet "are you there" query which doesn't affect the data in 
the tty session but is traffic on that tcp session. This query
It sends thos pings every 75 seconds once it starts, and only closes the 
connection if it fails to get an ack after sending 8 pings.
All 3 of those values are configurable.

That means that you could set the initial ping and the subsequent time 
between pings to however short you need so that your particular tcp session 
idleout nazis don't decide it's idle.
Yet, you can set the number of allowed failures to high enough to allow the 
session to survive and resume after as much transient-broken-network time as 
you want, instead of the first failed ping closing the connection.
And since this is all done by the server, the client can beconfigured not to 
generate it's own keepalives, so the client would remain ignorant of a 
transient breakage and so, survive it.
And yet, if the connection really does break, or the client really does 
close ungracefully, the server daemon will eventually know it and clean up 
shop.

So, best of both worlds.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!