[Ns-bugs] [Bug 162] Calling Object::AggregateObject twice with the same Object type silently succeeds

bugzilla-daemon@nsnam-www.ece.gatech.edu bugzilla-daemon at nsnam-www.ece.gatech.edu
Thu Apr 10 09:24:01 PDT 2008


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





------- Comment #13 from craigdo at ee.washington.edu  2008-04-10 12:24 -------
There are two issues here.  The first is the actual bug.  It *is* a programming
error to attempt to aggregate more than one "interface" of a given type.  That
should assert, which will address bug 162.

The second issue is what semantics of Install in the helpers are.  I tend to
look at the building of topologies like people building networks in reality. 
If I were to give you a phone call and say, "please install the ns3 protocol
stack on computer X," you'd go to that computer and find a stack already there.
 The question is what do you do now?  Do you get excited and call back, saying
"it's a disaster, there'e already one there" (ERROR) or do you call back
saying, "it's okay, someone else got to it first so I just left it alone"
(NOERROR).

It seems quite simple at first, but as Mathieu is trying to explain, it can get
tricky.  In the simple case (one kind of internet stack), the answer is simple
and you can make the case that the NOERROR approach from above works fine. 
What if there are two internet stacks in play in the system of the same type
(one *replacing* the other)?  What if you want to install stack of kind 2 on a
node that already has kind 1 aggregated.  In this case, Install of stack 2
would silently pass and you'd have a system that was subtly and quietly
different than you expected.  This is very bad.

Having semantics where Install says, "please ensure that this action is done
exactly once" is easy and makes sense in the simple case; but it can cause
horrible problems if you try to do perhaps unexpected things.

The same set of arguments actually applies to all of the helpers.  In previous
versions of the helpers, I was playing with the concept of an "external" node
to prevent this from happening.  If the "external" bit was set, I assumed that
features were previously added by a set of helpers external to the currently
running set.  The "external" bit was set when you Add()ed a node to a
container.

In the current model of how the helpers are used, this is really no longer
possible.  In many of the examples, you create N nodes in a container and then
add them to various other containers which are eventually used to Install() the
other pieces -- often *all* of the nodes are external in the sense I used them
previously.  Basically anything can come from anywhere with no restrictions or
assumptions, which is what Mathieu wanted, I suspect.

Given the current helper architecture, and the bad things that can possibly
happen, I think Mathieu is on the right track here.  Just pass through the
request to aggregate a second time and assert.  If you assert, fix your script
so you don't assert.


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


More information about the Ns-bugs mailing list