[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 #23 from Antti Mäkelä <zarhan at cc.hut.fi>  2010-04-29 14:17:22 EDT ---
(In reply to comment #22)
> Here is how I understand what is happening based on your description and the
> pcap.  Please let me know if I am incorrect.  The initiator calls Close, sends
> a FIN, and enters FIN-WAIT-1.  The responder sends some ACKs and a few DUPACKS,
> but does not yet ACK the FIN. 

  True so far. You see that client (responder in your terms) sends back dupacks
with ACK around 44k in the dupack (total transfer is 50k) - thinking that
packets have been lost on the way. The server (initiator in your terms) starts
re-sending them packets, but before it gets to the end, the client sends a new
ACK indicating that ALL data made it through after all.

> It does, however, enter the CLOSE-WAIT state. 

  I don't think it does. Shouldn't it call NotifyClose() anyway? I think
NotifyClose() should be called at the same time as the responder sends that ACK
indicating that everything has been transferred.  

> It will sit here until its application is closed, which you do later in the
> simulation. 

  Yes, and this happens because NotifyClose() never gets called and the
application doesn't know that peer terminated session! 

  What happens now

Server (I don't have Wireshark on this computer so sequence numbers are from
memory) sends following packets:

Data (44k), Data(46k), Data(48k), Data (50k, FIN set)

Client

Ack(44k), Ack(44k), Ack(44k)

Server notices three DupAcks, starts again with

Data(44k)

However, at this moment Client notices that subsequent packets, INCLUDING the
FIN made it through after all, and sends

Ack(50k) - However, NotifyClose() is NOT called at this point! So the
application never finds out that peer has sent a FIN and closed the connection
from their end!

At this point the server stops sending any further data and just waits for FIN
from the peer (as it should), however, the peer APPLICATION is not aware and
never knows that server has closed...

If a TCP session does NOT send the dupacks after server has sent FIN, the
NotifyClose() gets called properly right after it has been received and
acknowledged, so application can immediately say socket->Close() and terminate
both ends.

I can try taking a look at the code tomorrow myself but basically what happens
is that if you receive a FIN-packet, NotifyClose() SHOULD be called when that
FIN-packet gets acknowledged, no matter if there has been retransmissions on
the way.

The unfortunate thing for debugging this is that it pretty much requires
congestion. Right now I get this to appear by having 30 tcp sessions at once -
and only in one of them these symptoms appear. I'm not yet that familiar with
gdb - how can I set a breakpoint that only triggers with a specific instance of
class (in this case, just the single TcpSocketImpl where this issue occurs, not
the 29 others).

-- 
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.