Date: Fri, 15 Nov 2013 08:03:22 -0800 From: Charles Swiger <cswiger@mac.com> To: Andrew Schmidt <Andrew.Schmidt@impactmobile.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Question regarding RST packet and the tcp stack Message-ID: <D06DB30E-A26C-47CA-8722-7E84B922772A@mac.com> In-Reply-To: <AB6DCFC5655620408374E392D11AB44E10ED5AEE@exchange1-tor.impactmobile.local> References: <AB6DCFC5655620408374E392D11AB44E10ED55FA@exchange1-tor.impactmobile.local> <B5AB96FB-4FDF-491A-8C49-C40F559805A4@mac.com> <AB6DCFC5655620408374E392D11AB44E10ED5AEE@exchange1-tor.impactmobile.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi-- On Nov 15, 2013, at 7:22 AM, Andrew Schmidt = <Andrew.Schmidt@impactmobile.com> wrote: > Apologies in advance, but can you confirm that a "CLOSE" means either = a FIN or RST? "CLOSE" corresponds to when one side calls close(2) in userland. The = TCP stack will send any remaining unsent bytes and then a FIN, moving = the connection from ESTAB to FIN-WAIT-1; the other side of the = connection which receives a FIN moves to CLOSE-WAIT. (See state diagram = around page 22.) > I've read this section over and over, and I still don't fully = understand where it confirms those bytes should be readable (I'm sure = you are correct, but I just need to be able to explain this to someone = else, and right now I'm not 100% clear) Well, read other parts of the RFC.... > For instance this part: >=20 >> 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. >=20 > Seems to be talking about the side that is closing the connection = (which in my example is the remote side). Which side wants to close first doesn't have a bearing on data being = sent from the other side. > I'm more interesting in the receiving / host side which hasn't closed = any part of it's connection and receives those 3 separate packets (PSH, = PSH+ FIN, RST) PSH flag isn't relevant to the connection lifecycle. Receiving a FIN = means the other side is done and has no more data to send. Receiving a = RST is not normal, but there are lots of buggy network stacks (or sysctl = tuning for busy webservers) which drop the TCB sooner than 2*MSL aka ~4 = minutes timeout rather than waiting. Regards, --=20 -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D06DB30E-A26C-47CA-8722-7E84B922772A>