[Ns-bugs] [Bug 424] TCP FIN notification callback needed

[code@nsnam.ece.gatech.edu]

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


Tom Henderson <tomh at tomh.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|raj.b at gatech.edu            |tomh at tomh.org




--- Comment #9 from Tom Henderson <tomh at tomh.org>  2009-06-29 01:26:59 EDT ---
I think there are two problems identified in the comments below.

Problem 1) if the peer closes and sends a RST, then the sender should be able
to detect this.  In a normal implementation, recv () would return -1 and errno
would be set to ECONNRESET.  In ns-3, using the Ptr<Packet>-based API for
receive, there is no way to convey this presently.  Using the byte-based recv()
API that returns an int, there still is not a way to convey this because that
method simply calls the Ptr<Packet>-based method.

A couple of options to fix the above API problem:
1) modify existing NotifyDataRecv() callback in Socket base class as follows:
- void SetRecvCallback (Callback<void, Ptr<Socket> >);
+ void SetRecvCallback (Callback<void, Ptr<Socket>, int >);
where the int can be used to signal "-1" to the function handling recv
callbacks
2) add a new callback such as RecvError callback that is invoked whenever read
would have returned -1 in a sockets implementation

I think that this bug could be renamed:  TCP RST notification needed

Problem 2) People seem to want a callback that mimics a blocking close with
SO_LINGER semantics.

For this, I think this is not a bug but a feature request to add SO_LINGER, and
some kind of a CloseCallback that signals when the system would have either
returned from a lingering close or timed out.  For this, a new bug could be
opened.


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