>>>>> "Scott" == Scott L Burson <gyro@zeta-soft.com> writes:

Scott>    Date: Sun, 11 Feb 1996 21:40:38 -0600 From: "Michael Graff"
Scott> <explorer@flame.org>
   
Scott> Oh -- I guess I left out a key piece of information: we use
Scott> large, long- running CASE applications here that build up large
Scott> amounts of state within the process (250MB process sizes are
Scott> not unusual around here).  It can be a major hassle to rebuild
Scott> that state after logging out and logging back in.  This is
Scott> exactly what we are trying to avoid.

If this is jobs run from shell (as opposed to say X-apps) I'd
recommend either running them in batch if possible (via either
at/batch/nohup/whatever) or via "screen".  Even if TCP didn't time out on
you, I'd feel a lot safer as then crashes on the client TCP stack
would not hurt you either.  With lasting TCP connections all you
survive is line drops, not total client dropouts.

Michael> 			    TCP connections shouldn't survive 24 hours
Michael> of interruption in network connectivity.  In fact, I believe
Michael> there are standards that would be violated all over the place
Michael> by allowing this sort of thing.  Perhaps you should get the TCP
Michael> RFC and read it?

I read 793 once again (I did last year as well when I was pissed at
the BSD way of timing out TCP connections).  At least in there I could
not see any rationale for doing this.  I'm going to add an option to
my kernel (probably a sysctl) to make it possible to control the
number of retransmits before resetting the connection.  Perhaps I'll
add a user-level connection resetter as well..

Niklas

Niklas Hallqvist       Phone: +46-(0)31-40 75 00  Home: +46-(0)31-41 93 95
Applitron Datasystem   Fax:   +46-(0)31-83 39 50  Home: +46-(0)31-41 93 96
Molndalsvagen 95       Email: niklas@appli.se     GSM:  +46-(0)70-714 10 35
S-412 63  GOTEBORG     WWW:   Here
Sweden		       IRC:   niklas (#NetBSD)    ICB:  niklas (netbsd)