Bugzilla – Bug 2565
TCP: do not wait for 2*MSL to notify socket close
Last modified: 2017-09-17 11:29:22 EDT
Socket::NotifyNormalClose() notifies application of a socket closing normally. This is supposed to mimic the 'read() returns zero bytes' in conventional socket programming. In current implementation, for the normal closing sequence, TcpSocketBase makes this call in the CloseAndNotify() method upon moving to state CLOSED, both from LAST_ACK->CLOSED and TIME_WAIT->CLOSED. However, deferring it until TIME_WAIT->CLOSED means that we wait 2*MSL (240 seconds). I believe that TcpSocketBase() CloseAndNotify() should instead be called upon moving into TIME_WAIT state instead of upon leaving it; that is, call: NotifyNormalClose (); m_closeNotified = true; upon entering TIME_WAIT. The existing behavior to also call in transitioning from LAST_ACK to CLOSED can stay the same. If there is agreement on the behavior change, I can provide a patch.
Hi, I remember someone complaining about that in the ns-3-users mailing list times ago, but the decision (at time) was to document the behaviour without changing it. In details: (In reply to Tom Henderson from comment #0) > Socket::NotifyNormalClose() notifies application of a socket closing > normally. This is supposed to mimic the 'read() returns zero bytes' in > conventional socket programming. This is not written on the documentation; it says, for NotifyNormalClose: """ Notify through the callback (if set) that the connection has been closed. """ and, in case of TCP server-side, this happens after 2*MSL, as you correctly reported. > I believe that TcpSocketBase() CloseAndNotify() should instead be called > upon moving into TIME_WAIT state instead of upon leaving it; In that particular case, I'm not against such a patch, since this is the behaviour an user wants to track. But we should state somewhere (documentation, tutorial, etc) that the thing changed in response to a community need, but that we are, in some way, inserting a lie: the connection is not really closed, just in a state that ends after a very long period of time.
> > In that particular case, I'm not against such a patch, since this is the > behaviour an user wants to track. But we should state somewhere > (documentation, tutorial, etc) that the thing changed in response to a > community need, but that we are, in some way, inserting a lie: the > connection is not really closed, just in a state that ends after a very long > period of time. I don't think it is a lie, but I am fine with modifying the documentation to explicitly state that "it is called in TCP upon entering TIME_WAIT or leaving LAST_ACK states (i.e. before waiting that may occur TIME_WAIT state)." That the TCP sometimes waits before moving to CLOSED doesn't change that the socket has already closed normally and packet exchanges are over. I will provide a patch if no other comments.
code was fixed in changeset 12915; documentation was checked in by changeset 13067