[Ns-bugs] [Bug 818] TCP Socket implementation does not set ACK flag on retransmits

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=818





--- Comment #15 from Tom Henderson <tomh at tomh.org>  2010-04-20 02:18:24 EDT ---
(In reply to comment #14)
> Created an attachment (id=835)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=835) [details]
> Fix by adding new event
> 
> Here is what I've come up with given Tom's suggestions.  I will still be
> thinking about this throughout the day though, and I welcome and comments on
> the patch.  Note that for the test suite that was failing (tcp), the only
> change that was absolutely needed for the test to pass was the one to the
> LAST_ACK state.

I'm OK with this patch as long as it passes tests for you.

> 
> Some thoughts:  Should we really be getting anything other than an ACK to a FIN
> in the LAST_ACK state?  If so, should NO_ACT action be applied, as I am doing
> now?  Same thought for CLOSING state.

In general, IP networks can drop, reorder, and duplicate packets, so I would be
liberal in assuming what could arrive.  In LAST_ACK or CLOSING state, I imagine
that retransmissions may still be needed in some data loss cases, but if you
read through the peer's FIN, then you shouldn't get new data from the peer.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.