chm@opus.UUCP (04/14/87)
The 4.2 TCP keep-alive implementation is described two different ways. According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires we should send the following segment to elicit a response from our peer: <SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK> But, the actual implementation in our version of tcp_timer.c sends: <SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK> Note that the first segment contains an invalid SEQ and the second contains both an invalid SEQ and an invalid ACK. My question is, do we really need to lie about what we've received by sending an invalid ACK or is the invalid SEQ enough to elicit a response? -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710
CERF@A.ISI.EDU.UUCP (04/14/87)
Paul, In the absence of a no-op, something which sends no data but is guaranteed to elicit a response is the option chosen. Vint
netnews@orstcs.UUCP (04/15/87)
/* Written 3:31 pm Apr 13, 1987 by chm@opus.UUCP in orstcs:comp.protocols.tcp-ip */ /* ---------- "4.3 TCP keep-alive question" ---------- */ The 4.2 TCP keep-alive implementation is described two different ways. According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires we should send the following segment to elicit a response from our peer: <SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK> But, the actual implementation in our version of tcp_timer.c sends: <SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK> Note that the first segment contains an invalid SEQ and the second contains both an invalid SEQ and an invalid ACK. My question is, do we really need to lie about what we've received by sending an invalid ACK or is the invalid SEQ enough to elicit a response? -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 /* End of text from orstcs:comp.protocols.tcp-ip */
karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP (04/19/87)
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
cetron@utah-cs.UUCP (04/19/87)
In article <...> karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes:
->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
After spending a week hacking keep-alives into the Tektronix TCP/IP
code, I too was quite frustrated when many ultrix users kept calling and
complaining about there windows disappearing. After much poring through both
the 4.2/4.3 keep alive code and comparing it against the ultrix 1.2 code it
became obvious that ONE SINGLE LINE OF CODE IS MISSING in the ultrix networking
code. Seems it gets the keepalive, figures out it is a keep alive and then
doesn't have that ONE LINE OF CODE which tells the kernel to send out an ack.
Looks to me like a typo deleted a line by mistake. I posted this
fact here quite a while ago, passed it on to some friends at dec, and would
have filed an SPR but I don't have any Ultrix systems to file it under. I
had hoped it would be fixed in V2.0 but I quess not. Maybe if I shame the
Ultrix people in Nashville next week :-)
-ed cetron