[Ns-developers] ns3 - removal of Socket::HalfClose callbacks

[Tom Henderson]

Mathieu Lacage wrote:
> hi raj,
> 
> As a user, here is my understanding of what was expected to happen. 
> 
> If I am A and I am connected to B, I can get two types of closure
> events:
> 
>   - I request a half-close with B so, I send a FIN with a shutdown
> (WRITE). I want to be notified when I receive the ACK for this FIN. The
> reception of this ACK is one type of closure event.

Shouldn't this callback be associated with ShutdownSend?  And I think 
you want to wait for the peer's FIN and not the ack of your FIN.

> 
>   - B requests a half-close with me so, B sends a FIN and I have to
> reply with an ACK. The reception of this FIN is one other type of
> closure event.
> 
> So, to comment about the two types of callbacks you mention below, it is
> my understanding that they are used to identify the two different kinds
> of closure events I identified above. I personally don't care much
> whether you really want to tell the difference between the two kinds of
> closures but I guess that this is the rationale for the current API.
> However, as you point out, this is not very well documented (and,
> although I did not come up with this part of the API myself, I am to
> blame for the documentation I think :).
> 
> So, to summarize, is your proposed fix ok ? I don't know. It depends on
> what the use-cases are for the various closure events. For example, one
> question is: is the synchronous shutdown (WRITE) specified in the BSD
> socket API blocking until we get the ACK for the FIN we send ? 

This is the case where shutdown is called and read blocks, so the 
application can tell whether the peer has read all of its data; this 
seems to be a common enough use case.  The halfClose callback could be 
associated with the peer's FIN arriving (i.e., the read unblocks).

If this
> is so, then, we need the callback for that FIN to be able to unblock the
> caller of a synchronous API built on top of this async API. As for the
> other kind of closure event (the FIN sent by the remote side), I have to
> confess that I have a hard time figuring out what I would use it for.

I agree; I do not see how this would typically be used.

The callback scenarios that seem to be of typical interest are the 
halfClose callback associated with shutdown write, and the close 
callback when SO_LINGER is set on the socket.  I would suggest to remove 
closeRequested, keep closeCompleted, and keep halfClose but associate it 
with Shutdown() instead of Connect().

Tom