From owner-freebsd-net@FreeBSD.ORG  Fri Jul 20 22:43:04 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 31F1616A41F
	for <freebsd-net@freebsd.org>; Fri, 20 Jul 2007 22:43:04 +0000 (UTC)
	(envelope-from karels@redrock.karels.net)
Received: from redrock.karels.net (redrock.karels.net [206.196.45.2])
	by mx1.freebsd.org (Postfix) with ESMTP id DF62D13C468
	for <freebsd-net@freebsd.org>; Fri, 20 Jul 2007 22:43:03 +0000 (UTC)
	(envelope-from karels@redrock.karels.net)
Received: from redrock.karels.net (localhost.karels.net [127.0.0.1])
	by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6KMdSq4035780;
	Fri, 20 Jul 2007 17:39:29 -0500 (CDT)
	(envelope-from karels@redrock.karels.net)
Message-Id: <200707202239.l6KMdSq4035780@redrock.karels.net>
To: Julian Elischer <julian@ironport.com>
From: Mike Karels <karels@karels.net>
In-reply-to: Your message of Fri, 20 Jul 2007 10:55:18 -0700.
	<46A0F706.6020701@ironport.com> 
Date: Fri, 20 Jul 2007 17:39:28 -0500
Sender: karels@karels.net
Cc: FreeBSD Net <freebsd-net@freebsd.org>,
	Julian Elischer <julian@elischer.org>
Subject: Re: Wierd networking. 
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: karels@karels.net
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2007 22:43:04 -0000

> I think that the possible courses of action are:

> 1/ Ignore further incoming data, but ACK it.
>       (this is basically what the userland code does in this case)

This could lead to indefinite data transfer, while misleading the sender
into thinking the data are being delivered.

> 2/ Stop ACKing the data, and let the other end time out.

This seems like a waste of resources on both ends of the connection;
both are doomed, but they both have to time out to go away.

> 3/ Send a RST

This is my choice, literally: I added the code to send a RST in this
case sometime in the 1980s, after observing connections that hung
with no reader, but with the writer in persist mode indefinitely.
(That's choice 4: accept the data, let the receive buffer fill, then
advertise a zero window forever.)

		Mike