From owner-freebsd-net@FreeBSD.ORG Fri May 1 16:51:50 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D232E1065680 for ; Fri, 1 May 2009 16:51:50 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id AA8A88FC0C for ; Fri, 1 May 2009 16:51:50 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 0F00B5C5F; Fri, 1 May 2009 12:25:15 -0400 (EDT) Message-Id: <608FDC77-03A7-47E5-B992-6B0ECC1BFACE@transsys.com> From: Louis Mamakos To: net@freebsd.org In-Reply-To: <9639.1241172701@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 12:25:14 -0400 References: <9639.1241172701@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: Poul-Henning Kamp Subject: Re: SO_LINGER + shutdown(2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:51:51 -0000 On May 1, 2009, at 6:11 AM, Poul-Henning Kamp wrote: > > I was somewhat surprised to see that calling shutdown(SHUT_WR) on > a TCP socket with SO_LINGER set {.l_onoff =3D 1, .l_linger =3D 0} does > not in fact flush the send queue orderly, but immediately RST's the > connection. > > I realize this is an issue for the Dept. of deep TCP arcan=E6 and not > something to be changed lightly, so consider this more of an > observation than bug report. > Setting aside for the moment what applications might rely on this behavior, this seems unexpected and perhaps wrong to me. The intent of the shutdown() system call in this instance ought to be to indicate that the local end of the connection has no additional data to transmit to the remote TCP peer. But it ought to continue to allow additional data to be read from the connection. Sending a reset segment to the far end will hardly enable that behavior. The remote TCP will abandon the connection and there will be no further data forthcoming from it (aside from what might be in flight.) If the local TCP connection has already received a FIN segment from the far end and is in CLOSEWAIT state, then perhaps that's a bit of a different animal.. louie=