From owner-freebsd-net@FreeBSD.ORG Fri Nov 15 15:22:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD435DE8 for ; Fri, 15 Nov 2013 15:22:46 +0000 (UTC) Received: from corp1.jumptxt.com (corp1.jumptxt.com [66.207.219.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5612065 for ; Fri, 15 Nov 2013 15:22:45 +0000 (UTC) Received: from owa.impactmobile.com (office-tor.impactmobile.com [72.15.57.66]) (authenticated bits=0) by corp1.jumptxt.com (8.13.8/8.13.8) with ESMTP id rAFFMcgO025430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 15 Nov 2013 10:22:38 -0500 Received: from EXCHANGE1-TOR.impactmobile.local ([::1]) by exchange1-tor.impactmobile.local ([::1]) with mapi id 14.01.0218.012; Fri, 15 Nov 2013 10:22:37 -0500 From: Andrew Schmidt To: Charles Swiger Subject: RE: Question regarding RST packet and the tcp stack Thread-Topic: Question regarding RST packet and the tcp stack Thread-Index: Ac7hPNQspl1jJCzLQD+WjmXpa5CX7AAUzB+AACErM1A= Date: Fri, 15 Nov 2013 15:22:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.1.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 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, 15 Nov 2013 15:22:46 -0000 > "3.5. Closing a Connection >=20 > CLOSE is an operation meaning "I have no more data to send." The > notion of closing a full-duplex connection is subject to ambiguous > interpretation, of course, since it may not be obvious how to treat > the receiving side of the connection. We have chosen to treat CLOSE > in a simplex fashion. The user who CLOSEs may continue to RECEIVE > until he is told that the other side has CLOSED also. Thus, a program > could initiate several SENDs followed by a CLOSE, and then continue to > RECEIVE until signaled that a RECEIVE failed because the other side > has CLOSED. We assume that the TCP will signal a user, even if no > RECEIVEs are outstanding, that the other side has closed, so the user > can terminate his side gracefully. A TCP will reliably deliver all > buffers SENT before the connection was CLOSED so a user who expects no > data in return need only wait to hear the connection was CLOSED > successfully to know that all his data was received at the destination > TCP. Users must keep reading connections they close for sending until > the TCP says no more data." Apologies in advance, but can you confirm that a "CLOSE" means either a FI= N or RST? I've read this section over and over, and I still don't fully understand wh= ere it confirms those bytes should be readable (I'm sure you are correct, b= ut I just need to be able to explain this to someone else, and right now I'= m not 100% clear) For instance this part: > A TCP will reliably deliver all > buffers SENT before the connection was CLOSED so a user who expects no > data in return need only wait to hear the connection was CLOSED > successfully to know that all his data was received at the destination > TCP. Seems to be talking about the side that is closing the connection (which in= my example is the remote side). I'm more interesting in the receiving / h= ost side which hasn't closed any part of it's connection and receives those= 3 separate packets (PSH, PSH+ FIN, RST) > > I've looked over the TCP rfc: http://www.rfc-editor.org/rfc/rfc1122.tx= t . >=20 > The TCP RFC is: http://www.ietf.org/rfc/rfc793.txt Sorry, that was a bad copy/paste Thanks for your help Andrew,