[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 #14 from tomh at tomh.org  2008-03-28 00:12 -------

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

Yes, but I think it is not completely clear cut.  We are debating the issue of
what happens if the user forgets to close the socket.  In your proposal, we
could leak sockets (descriptors) in such a case.  As presently implemented, we
would delete the socket instead of closing it.  Neither really captures what
happens in real code, in which close() is called when the process goes away
before the user closed it.

Your and Raj's proposal would err on the side of keeping sockets around, and I
would be fine with that, because I think it would be less intuitive to a user
to have sockets disappear without even an implicit close() ever having
occurred.  This is probably more relevant to consider with TCP but might be a
problem with UDP if we ever model the case where the UDP socket didn't
immediately send the datagram for some reason. 

there is the separate issue of whether ns-3 should do something when methods
like Test::Run() are called before Simulation::Run() is called.  Clearly, it
will provide undefined behavior to use parts of the API outside of a running
simulation context.  Do we want to try to guard against this misuse somehow?


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