Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: probing in TCP
Message-ID: <9387@ucbvax.ARPA>
Date: Sat, 27-Jul-85 02:58:52 EDT
Article-I.D.: ucbvax.9387
Posted: Sat Jul 27 02:58:52 1985
Date-Received: Mon, 29-Jul-85 05:29:21 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 14

From: don.provan@CMU-CS-A.ARPA

The time I need to probe a connection most is not one of the three
mentioned.  That's when there was a user, but there isn't any more.
For example, an inbound Telnet connection will sit around tieing up
resources forever if the remote host goes down while nothing's
happening on the connection.  I implemented it as a general solution,
since I can't imagine a connection where that can't happen.  After
all, the connection is a TCP resource.  There's no way for me to
determine whether the TCP connection or the network links in use for
it are more valuable.  In fact, I only implemented probing because
TCP keep running out of connection blocks.

For the curious, I probe with spontaneous ACKs.