[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 #16 from gjcarneiro at gmail.com  2008-03-28 06:34 -------
(In reply to comment #14)
> 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.

If you wanted to capture what _really_ happens in the real world, then sockets
would always have to belong to applications, and be conceptually attached to
applications:

  Ptr<Socket> SocketFactory::CreateSocket (Ptr<Application> application);

Since in the real world sockets are created by _processes_ making a system call
into the kernel.  The kernel would implicitly receive the process ID as
"parameter" and would associate the newly created socket with the process.

In NS-3, because users do not want to have to write new application classes
(ugh!), we would need a 'generic' application.

Ptr<GenericApplication> Node::CreateApplication ();

Applications would then be release their own sockets when they are destroyed.

I think the above model would mimick best what happens in real world.  However,
if applications are only destroyed when a node is destroyed, or when the
programmer explicitly destroys them, their sockets will consequently also only
be destroyed when the application is explicitly destroyed or when the node is
destroyed.  And so this ultimately reallistic API turns is reduced to my
proposed solution where sockets are destroyed explicitly or when the Node is
destroyed.

I am in favour of making the Application "middle man" optional (personally I
tend to never use it), and just allow sockets to be used directly.

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

What if I create a OnOff application and forget to dispose it?  It will keep on
sending traffic forever...  same problem.

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

The logical solution would be:
1. Most APIs, like socket creation, fail an assertion when called and the
simulator not running;
2. It would force programmers to do the simulation initialization stuff in a
callback, scheduled with Simulator::ScheduleNow;

But I don't think that would help.  The Simulation initialization function
would still create a local variable smart pointer, create the socket, and it
would still go out of scope and destroy the socket before time.


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