Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!SH.CS.NET!gwilliam
From: gwilliam@SH.CS.NET (George Williams)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Keep-Alive within TCP
Message-ID: <9009110311.AA01898@ucbvax.Berkeley.EDU>
Date: 10 Sep 90 14:22:51 GMT
References: <1990Sep7.002637.6209@ingres.Ingres.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 77



Please note the following in regards your query:

 () "keep-alive" is used rather loosly in the TCP/UNIX environment.
    ( Correct and enlighten me as appropriate.) 

    1. I have seen it used to describe an option under UNIX to determine
       whether or and for how long to "re-try" a client initiated
       connection request to a server process. This is usually done under
       the covers, i.e. transparent, to the requesting process.

    2. Some vendors implement it, again option defined, to periodically
       poll the other end of an established connection in order to
       solicit a response indicating "am still here alive" from a peer
       TCP transport. This feature has proven useful to applications
       designed for paralellism or some degree of concurrency relative to
       higher level processing requirements.


    Given the above it would be enlightening to one such as myself if you 
    would elucidate as to which if any of the above context you are 
    using the term "keepalive", i.e. could help define the implementation
    specific context of your query. 

    In the case of (1) above it has proven beneficial and helped to simply
    interface level programming logic requirements to have this feature,
    based on prior development ( subjective ) work in this area.


    As far as (2) , again, it proved to be a useful feature; in lieu of a
    timeout parameter on most UNIX implementations for network read and write
    calls, in avoiding "hung" processes and in the area of process management.
    In distributed compute environments  determination of 'when' a 
    process/service/application is 'really' alive can be a problem depending
    on what OS/CPU combination a process is executing under, just to mention
    one consideration. I won't mention any vendor by name ( some
    of observed problems in this area may have been corrected, even as we
    speak ), but some OS's have been noted to max out or approach 100%
    CPU utilization as a result of process or application level loops for
    retrys on network open/read/write failure attempts. Granted that this
    is the indication of a poor design on the application level, network
    software developers have to take the broad(er) perspective that programmers
    don't want to know the detail of underlying protocols much the same
    as we don't necessarily want to get into application specific  
    implementation details.

 () OSI TP0 and TP4 specify connectionless and connection oriented transport
    service by way of architectural definition. It comes as no surprise that
    the connection oriented service would be rigid in the service and protocol
    specification for the know state of an end to end or peer connection.
    Rationale, one would assume,include some if not all of the aforementioned.
    Not to mention the tradeoff beteeen end to end service association versus
    simple protocol, and I assume infrequent, exchange of "keep-alive"
    information.( I stand to be corrected here, but it's sound logical to me
    so I'm probably way off base ,SMILE. ) You can probably make a better
    statement in this area than I am prepared to.

    TCP, ostensibly, takes the least-common-denominator path to solution 
    from all have been able to determine, based on implementation experience.
    In other words by design ( there is no application or session layer )
    the path that offers the least protocol overhead appears to have been
    chosen for support of end to end transport level connectivity. It looks
    like ( and I make the statement with a limited frame of historical
    reference in this area ) "the right decision" based on the engineering 
    requirement(s) at that time.

 () I have seen vendors that don't or hadn't prior to this year implemented
    this feature as described for both case (1) and (2) above.  So I have
    always considered it an option that was product (vendor) driven. Work may
    be ongoing by some a Working Group to make it a protocol extension.


  
  George Williams
  BBN,STC