[Ns-bugs] [Bug 818] TCP Socket implementation does not set ACK flag on retransmits
code at nsnam.ece.gatech.edu
Mon Apr 19 23:18:25 PDT 2010
--- 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.
More information about the Ns-bugs