[Ns-developers] Bug 215 Name Container

[Gustavo Carneiro]

2008/12/1 <craigdo at ee.washington.edu>

> Hi All,
>
> regarding bug 215 (http://www.nsnam.org/bugzilla/show_bug.cgi?id=215) I
> have
> added a patch that implements a simple bidirectional map of ns3::Object vs.
> std::string to begin to address the name container issue.
>
> It's really just a simple beginning and is not completely integrated with
> the rest of the system yet, but it does give us a basic naming
> functionality.
>
> Here are some snippets from csma-one-subet.cc which I taught about names
> ...
>
> ---------- Begin Included Code ----------
>
>  NameList::Add (devices.Get (0), "Node 0/eth0");
>  NameList::Add (devices.Get (1), "Node 1/eth0");
>  NameList::Add (devices.Get (3), "Node 3/eth0");


Here I think the arguments should be swapped.  Normally we are used to
assignment where the identifier comes before the value.  It is that way in
Assembly, C, and Python (PyObject_SetAttrString(object, "string", value)).
I'm sure there are more examples of prior art that I could find... :-)

Do we really want to allow slashes in the names?  I could imagine a future
extension of that class to support tracing, e.g. Config::Connect
("/NameList/AccessPoint/DeviceList/0/Rx", ...).  Slashes would kind of
interfere with this scheme.


>
> [ ... ]
>
>  ApplicationContainer app = onoff.Install (NameList::GetObjectOfName<Node>
> ("Node 0"));
>
> [ ... ]
>
>  CsmaHelper::EnablePcap ("csma-one-subnet", "Node 0/eth0");
>  CsmaHelper::EnablePcap ("csma-one-subnet", "Node 1/eth0");
>  CsmaHelper::EnablePcap ("csma-one-subnet", "Node 3/eth0");
>
> ---------- End Included Code ----------
>
> To be honest, I'm not sure that this is well-enough thought through to go
> in
> this release.  One example of an inconsistency is the trace file names.
> They will still come out like "csma-one-subnet-0-0.pcap" when I think they
> really should come out "csma-one-subnet-Node 0-eth0.pcap" or something
> similar.
>
> Also, there isn't good integration with attributes/tracing at a low level.
> For example, it would be nice to be able to refer to an attribute using the
> name list translation
>
>  "Node 0/eth0/EncapsulationMode"
>
> But this isn't implemented nor really thought through.


Indeed, it is not thought through.  I can see already that the
Config::Connect parser will be confused by the "Node 0/eth0" name...


>
> What are your thoughts about pushing this into ns-3.3?


It might be better to skip ns-3.3 to avoid possibly breaking the API in the
future.

One other idea occurred to me is to support object groups.

   NameList.:Add (std::string name, NodeContainer container);
   NameList.:Add (std::string name, DeviceContainer container);

For instance, you may want to connect to only the core routers, not edge
routers, in a hypothetical scenario:

Config::Connect ("/NameList/CoreRouters/*/....", ...)

The same thing with NodeList is difficult to do.  You have to do (IIRC):

Config::Connect ("/NodeList/[11-33]/...", ...)

where 11 and 33 and the start and end indexes of the nodes in that group.

To make this work you'd need some code that converts non-Ptr-based
NodeContainer to a Ptr-enabled ObjectContainer or something like that.  Idem
for the other containers.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert