Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!AHWAHNEE.STANFORD.EDU!dcrocker
From: dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SO_KEEPALIVE considered harmful?
Message-ID: <8906101638.AA06174@ucbvax.Berkeley.EDU>
Date: 10 Jun 89 15:34:23 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

Steve,

Let me try, one last time:

If the application can direct TCP as to the periodicity and the action
to be taken (notify application vs. abort connection) then the application
will not abort your connection unless the application programmer decided
to force that condition.  Under proper design, the programmer will give the
user a switch to set, indicating something about the "persistance" that
is desired.

With respect to having the mechanism in tcp or the application, I agree with
you, philosophically, that the mechanism should be in the application (although
I believe the OSI model would put it into the session layer, but that seems
mostly to be part of the application process, these days.

The major issues, however, are kernel vs. user space, and additional
complexity to the application protocol.

There is a remarkable economy that derives from puting this mechanism
into the kernel/transport system.  It may be an accident that TCP does
not have the mechanism but can be tricked into creating one, but it still
is remarkably simple.

Most application protocols have very simple interaction styles and tend to
be relatively easy to program.  To force time-based generation of action
would complexify these protocols significantly.

Dave