Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!trwatf!rlgvax!jds
From: jds@rlgvax.UUCP (Jack Slingwine)
Newsgroups: net.unix-wizards
Subject: Re: Purge 4.2BSD TCP tasks in FIN_WAIT_2
Message-ID: <615@rlgvax.UUCP>
Date: Wed, 24-Apr-85 11:14:53 EST
Article-I.D.: rlgvax.615
Posted: Wed Apr 24 11:14:53 1985
Date-Received: Fri, 26-Apr-85 22:09:14 EST
References: <377@wdl1.UUCP> <1661@ut-sally.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 20

> If you have many connections to TOPS-20 hosts, you will accumulate
> FIN_WAIT_2 state connections rapidly.  Here is a kludge that we have
> used at U. Texas for about two years, in 2.8BSD, 4.1C BSD, and 4.2BSD.
> It puts a timeout on the FIN_WAIT_2 state only (no effect on ordinary
> established telnet/ftp/rcp/rlogin connections).  It violates the TCP
> spec in that there is no such timeout in the spec.  However, we have
> never seen any ill effects from it, nor had any complaints, and it
> does away with the hanging FIN_WAIT_2 connections.

Unfortunately, it does cause trouble for the following:

	rsh other 'cd dir;tar cf - stuff' | (cd lcldir;tar xf -)

which allows you to "siphon" stuff off another machine.  For some reason,
"rsh" shuts down its send side of the stream, putting its end of the
connection in FIN_WAIT_2.  Depending on the amount of data to be sent, the
"2*TCPTV_MSL" timer could expire before all the data is transmitted.  I
suppose the least painful solution is to keep the FIN_WAIT_2 timer and
NOT shutdown the send side of the stream even though you don't plan to
use it.