Question regarding RST packet and the tcp stack

[Charles Swiger]

Hi--

On Nov 15, 2013, at 7:22 AM, Andrew Schmidt <Andrew.Schmidt at 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:
> 
>> 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).

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,
-- 
-Chuck