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

[Mathieu Lacage]

On Tue, 2008-01-15 at 12:09 +0000, Gustavo Carneiro wrote:

> > I can also see this as an *easy* way to get information out of the bowels
> > of
> > the system during or after simulations:
> >
> >   str = Get ("/nodes/1/tcpcraig/randomCounter");
> >   NS_LOG_INFO ("the random counter ended up as " << str);
> 
> 
>   Your proposal seems nice, but I would add:
> 
>   1- The ability to have named nodes.  Example:
>        Get ("/nodes/AccessPoint1/tcpcraig/randomCounter");

That would require that the user sets a node name when the node is
created.

> 
>   2- I think we should stop passing around values as strings: use the
> correct C++ type instead for Get/Set.

You should be able to do it both ways.

>   3- For language bindings it will be extremely useful that there exist
> addition parallel APIs that work with type/value pairs instead of just
> values, like "SetValue(std::string path, Ptr<const Value> value)", and
> "Ptr<const Value> GetValue(std::string path)", where value is a class like:
> 
> class Value
> {
>    public:
>       Ref ();
>       Unref ();
>       virtual Ptr<Value> Copy () const = 0;
>       virtual std::string AsString () const = 0;
>       virtual void SetFromString (std::string value) = 0;
> };
> 
> (the type can be obtained by typeid, no need to be an explicit member)
> and:
> 
> class BooleanValue
> {
> public:
>   BooleanValue ();
>   BooleanValue (bool value);
> };
> 
> This will allow e.g. the python bindings to define generic type conversion
> routines once (for each basic type) and call that conversion routine
> everywhere the Value class is used.

yes. The current Parameter proposal does this. I will attempt to send a
prototype sometime this week.

> Regarding all these topology issues, I must confess I am not too found of
> the topology APIs.  Basically I am not too fond of too high lelvel APIs, and
> in my simulations I prefer to just do my own for loops to create nodes etc.
> If I were to think of an ideal "topology" API to use, it would a bit lower
> level than what we have now.  I would welcome a set of APIs as building
> blocks to greater things I'd do myself, like:
> 
> 1- group = BeginGroup ()
> 2- for n in range(N) do
>   2a- Create Node
>   2b- Add a NetDevice to the node, given a technology name  (should match
> the channel type)
>   2c- Add the netdevice in 2b to the group
> 3- group.End ()
> 4- group.AddIpv4 ()
> 
> what 4. entails: 1. discover a unused IP subnet address;
> 2. for each node in group: a) add an IPv4 impl., b) re-add the netdevices to
> the ipv4 impl. c) assign unique ipv4 address, inside the assigned subnet for
> the group, for each netedevice;
> 
> 2, 2a, 2b could optionally be simplified by something like
> group.CreateNodes(int
> numNodes, ClassId netdeviceType);
> 
> Maybe my BeginGroup () is just a shameless copy of some ideas I read today
> regarding topology :)

I think that it is pretty close. 

> In any case, I would point out some things the topology code got it wrong
> IMHO:
> 
>   1- CsmaTopology and PointToPointTopology: why does topology have to be so
> attached to particular L2 technologies?

Well, these two classes should die as soon as we have a better
replacement.

> 
>   2- Need APIs to automatically assign IP subnets to groups, and unique IPs
> in the subnets to nodes/netdevices

I think that the topology proposal I sent this morning addresses this
through the use of the IpGenerator class.

>   3- Nodes could start as simple nodes first, upgraded in runtime to
> "internet nodes" as needed; this will allow us to have topology APIs that
> create topologies for L2 nodes, and the same API is useful for L3 nodes.

3) is indeed on the TODO: I think that it would make a lot of sense to
get rid of the InternetNode subclass of Node and replace it with an
InternetStack object which does not derive from Node and must be
aggregated by hand to the Node if you want the IP functionality. The
topology proposal I sent this morning does just this.

Mathieu