dennis@rlgvax.UUCP (Dennis.Bednar) (03/15/88)
How are TCP keep-alive request packets formatted? Is this a
data-less TCP packet that doesn't advance the sender's
sequence number field? What is the proper response; is it a
data-less packet (TCP hdr only) containing the same
acknowledgement number equal to the most recently transmitted copy
(ie a duplicate acknowledgement)?
As for the problem of some TCP implementations not responding
to "keep-alives", is this because the implementers decided
that it is unreasonable for the receiving TCP to respond to
a 0-length TCP data packet (ie a packet containing only the
TCP header)?
By the way, is the TCP "push" bit used for keep-alives?
And what exactly is the push bit used for? Last time I
read the TCP spec, I saw the mention of the bit, but no
practical description of what to use it for.
--
FullName: Dennis Bednar
UUCP: {uunet|sundc}!rlgvax!dennis
USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone: +1 703 648 3300karn@thumper.bellcore.com (Phil R. Karn) (03/15/88)
In BSD at least, keepalives are implemented by sending a TCP segment containing a single byte of "garbage". However, the SEQ field is one less than the receiver is expecting, so it is not accepted as real data. When the receiver sees an "old" data packet (i.e., a packet containing data that has already been acked, i.e., the sequence number in the header plus the length of its data is less than the receiver's RCV.NXT) it is required by the spec to send a segment with its next expected sequence number, i.e., RCV.NXT, in the ACK field. (This is primarily intended to prevent deadlock in normal data transfer should an acknowledgment packet be lost.) The "polling" TCP uses this "do-nothing ACK" as the indication that the remote host is still there. So hosts that don't respond properly to BSD-style keepalives are most likely not following the spec. Having said this, I should point out that keepalives are NOT a formal part of the TCP spec. I also think they're a very bad idea. I didn't always feel this way. However, some long and frustrating experiences with slow, unreliable and often expensive network paths (amateur packet radio, as well as commercial X.25 networks that charge for every packet) have turned me into a crusader against keepalive pinging. It simply isn't worth the cost, especially when there's no way for me to tell the other end to cease and desist. Besides, the whole philosophy of TCP and the datagram approach to networking was supposed to be reliability and robustness in the face of network problems. Why should the system gratuitously close a connection just because the network path happens to go down for a few minutes? If the connection has been idle during the entire outage, the user wouldn't even know (or care) that there had been a problem, as long as it's back by the time he sends more data. But keepalive pinging will make SURE he knows in the most annoying way possible! In the same category are TCPs that immediately close a connection when they get an ICMP Unreachable message. At most they should abort connections only before they are established; once established they should serve as diagnostic messages only. Phil
DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (03/22/88)
This seems to come up once a year. When I was implementing the Symbolics TCP implementation some 3 or 4 years ago, I asked about active connection sensing. The UNANIMOUS answer I got were that such things were 100% against the spec. Therefore, BSD is in error. [Philosophically, sending a garbage byte is disgusting.] What IS allowed, as far as I know, is to send a zero length IN ORDER TO ELICIT A RESET if the connection absolutely doesn't exist. This is what we do. Yes, it will cause packet traffic. If the link or remote host is down, the connection will not go away until active data is sent or the host comes up and IT declares that the connection doesn't exist. This will surely come up again in 10 to 14 months...