Date: Fri, 15 Nov 2013 15:22:37 +0000 From: Andrew Schmidt <Andrew.Schmidt@impactmobile.com> To: Charles Swiger <cswiger@mac.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: RE: Question regarding RST packet and the tcp stack Message-ID: <AB6DCFC5655620408374E392D11AB44E10ED5AEE@exchange1-tor.impactmobile.local> In-Reply-To: <B5AB96FB-4FDF-491A-8C49-C40F559805A4@mac.com> References: <AB6DCFC5655620408374E392D11AB44E10ED55FA@exchange1-tor.impactmobile.local> <B5AB96FB-4FDF-491A-8C49-C40F559805A4@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> "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,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AB6DCFC5655620408374E392D11AB44E10ED5AEE>