[Ns-developers] finalizing the ns-3 object model (configuration)

[Joseph Kopena]

On Jan 14, 2008 11:22 PM,  <craigdo at ee.washington.edu> wrote:
> I was thinking about this last Friday and it occurred to me that the
> namespace in our tracing system gets us almost there.  I have methods like
> the following scribbled on my whiteboard:
>
>   Set ("/nodes/*/tcp/reno/ssthresh", "16000");
>   Set ("/nodes/1/tcp/rajno/cwnd". "4000");

Hi all,

I must admit to being a little overwhelmed by this discussion.

However, this basic Set() idea looks appealing to me, but what is the
difference versus the current default value scheme?  It's not obvious
to me.  As it stands, I see the default value names as being somewhat
unstructured, and this sort of hierarchy could be nice, but that's
mostly a naming convention.

My understanding of the Params object was that it added a stack to the
default values such that you could enable local overrides.  I don't
think the Params object is so terrible, but it's not so awesome
either.  With mixed feelings about, I put forward that another
approach would be a global stack manipulator similar to Postscript's
gsave/grestore, i.e.:

... set some global parameters in program or console ...
... use global parameters
GSave(); // A new global state is pushed onto the stack, copying the
previous state
... ... set some local parameters
... ... use local parameters
GRestore(); // Global state is popped off, returning to the original
... use global parameters

I'm sort of with Gustavo in that I think strings are to be avoided,
but I think they'll be ok in this case as long as the Set() function
is very helpful.  I.e., if you pass in an unknown string, it should
complain very loudly & obviously (error message & throw an
exception?), and possibly even report similar strings for double bonus
points.

Care should be taken w/ Craig Set() functionality though.  For
example, if I call this line:

>   Set ("/nodes/*/tcp/reno/ssthresh", "16000");

After my simulation is all set up, will it change all the values for
all the nodes?  That sounds messy to implement, though possibly
useful.  I'd be mostly concerned about all object using the scheme to
then have to implement some sort of accessor functionality necessary
to traverse the key down to those objects.

> This could be written by scripts before they started creating objects or
> given by command line.  It could conceivably be done by reading an xml file
> that has lines that look like:
>
>   <set key = "/global/tcp/reno/ssthresh", value = "16000"/>

Or, possibly something like:

<configuration simulation="Award Winning Simulation">
  <params>
    <tcp>
      <reno>
        <ssthresh>16000</ssthresh>
      </reno>
    </tcp>
  </params>
</configuration>

Which could be nice and easily navigable (though verbose) XML, but
makes the star operator difficult.

Also, Gustavo, I think the "Topology" in the CSMA & P2P models is
mostly an artifact that could be changed.  There was a similar
discussion earlier about the current position/mobility helpers using
"topology" though they're really concerned with position, which may or
may not effect topology.

-- 
- joe kopena
  right here and now