Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: 4.3 TCP keep-alive question
Message-ID: <8704182219.AA08621@okeeffe.Berkeley.EDU>
Date: Sat, 18-Apr-87 17:19:45 EST
Article-I.D.: okeeffe.8704182219.AA08621
Posted: Sat Apr 18 17:19:45 1987
Date-Received: Sun, 19-Apr-87 07:41:56 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20

Curiously, I tried an experiment with keepalives a few weeks ago.
Your description of the comment in the 4.2 source isn't quite
accurate; the comment accurately describes what the code does,
but is wrong about the reasoning.  Both 4.2 and 4.3 send
	<SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK>
with one byte of (imaginary) data.  As you observed, sending
	<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK>
with no data should be sufficient to elicit a response.  However,
although 4.3 systems and Sun 3.x systems responded to such probes,
Ultrix 1.2 (and 2.0 field test) systems failed to respond, which
rather annoyed the users whose windows would disappear after some
minutes of inactivity.  I haven't tested this with more systems
because of the one failure; I don't have any stock 4.2's left
nearby.  Curiously, I started looking at this because someone
from the Ultrix group found a bug in handling resets generated
in response to a keepalive.  The reset may not be accepted,
as the sequence number will be one to the left of the window
using the current keepalive format.

		Mike