[Ns-bugs] [Bug 154] Attach sockets to nodes

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

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





------- Comment #10 from gjcarneiro at gmail.com  2008-03-27 19:49 -------
(In reply to comment #9)
> (In reply to comment #7)
> [snip]
> > What happens if a user releases the reference to the socket and he never calls
> > Close ?
> > 
> > I was thinking along similar lines but, for UDP, the lifetime of the socket is
> > much more problematic: i.e., it is not bound to an underlying stream which can
> > be closed or not by the remote side. So, if the user forgets to call Close, the
> > socket will live forever, even though it has data to send and cannot forward
> > its incoming data to anyone.
> > 
> > I might be worried about a non-issue though.
> 
> I think that the situation you are describing would become an error on the
> user's part under my proposal.

Hey, your proposal is the same as mine :-)

I just did not understand the implementation very well...

>  In the real world, if you don't call close on a
> socket, doesn't it persist indefinitely?  From this perspective, this is the
> correct behavior.

Agreed, a socket should live until told to die.  A smart pointer going out of
scope should not be enough to make a socket die.

> 
> The Socket WILL continue to deliver data up to the application however via the
> callback mechanism.  The Socket persists and has a pointer to the application
> upcall.
> 
> And luckily for us, Simulator::Destroy will eventually lead to
> UdpL4Protocol::DoDispose, which will delete it's demux, the destructor of which
> will delete each endpoint, the destructor of which will release the last
> reference to the Socket (the ones that live in the endpoint destroy and rx
> callbacks).  So this is shouldn't leak memory from a valgrind perspective
> either.

Indeed.

IMHO a socket, once created, should remain under custodian of its factory.  The
factory should remove its reference to the socket when either:
 1. the factory dies (and the factory dies when the node is disposed, at the
end of the simulation)
 2. it is explicitly closed, by calling Socket::Close ()
 3. the remote end point closes the connection, for connection oriented
sockets.

I don't think this costs much in terms of memory (at most 16 bytes per socket;
that's less than 1.6 MiB for 10^5 sockets).  And like Raj said, having to
close() sockets is already what happens in the real world.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.