Created attachment 153 [details]
Names patch

Some options here to consider:

1) whether to just overload GetNode(std::string name) instead of a separately named method GetNodeByName()

2) whether to add additional methods to return a node index or net device index (rather than Ptr) by name

+  if (found > 1)
+    {
+      NS_ASSERT_MSG (false, "More than one node with name: " << name);
+    }

Should probably be:
      NS_ASSERT_MSG (found <= 1, "More than one node with name: " << name);

Idem for device name.

Additionally it would be nice if Node::GetName would return "node%i" with the node number, in case no node name has been set.

(In reply to comment #3)

> 
> Additionally it would be nice if Node::GetName would return "node%i" with the
> node number, in case no node name has been set.
> 

Good idea.  

I bumped to P3 since we are still noodling on it-- proposed to check in after ns-3.1.

(In reply to comment #4)
> I bumped to P3 since we are still noodling on it-- proposed to check in after
> ns-3.1.
 
Sure.  Personally I had in mind using node name for "log context", but since the log context stuff was not fully implemented (and probably never will), this kind lost some of the appeal to me.

I am not volunteering to do any work, but it would nice to finish this for NS 3.3.

Mathieu suggested the following to me a little while ago:

class NameContainer
{
public:
  void Set (Ptr<Object> obj, std::string name);
  template <typename T>
  Ptr<T> Get (std::string name);
};

This allows any Object to have a unique name in the system, and doesn't cause all nodes to carry a std::string.  Thoughts?

by the way, I also would like to resolve this for ns-3.3.

(In reply to comment #7)
> Mathieu suggested the following to me a little while ago:
> 
> class NameContainer
> {
> public:
>   void Set (Ptr<Object> obj, std::string name);
>   template <typename T>
>   Ptr<T> Get (std::string name);
> };
> 
> This allows any Object to have a unique name in the system, and doesn't cause
> all nodes to carry a std::string.  Thoughts?

I don't like that:
  1. We have would Node::GetId () but no Node::GetName ();
  2. Everything gets put into the same namespace, nodes or whatever;
  3. There should be trace path support for node names, otherwise what's the point.

An intermediate possibility would be to put the names in the NodeList class.  That would make a lot of sense, conceptually, and avoid the need for each node to carry a name.

(In reply to comment #8)
> (In reply to comment #7)
> > Mathieu suggested the following to me a little while ago:
> > 
> > class NameContainer
> > {
> > public:
> >   void Set (Ptr<Object> obj, std::string name);
> >   template <typename T>
> >   Ptr<T> Get (std::string name);
> > };
> > 
> > This allows any Object to have a unique name in the system, and doesn't cause
> > all nodes to carry a std::string.  Thoughts?
> 
> I don't like that:
>   1. We have would Node::GetId () but no Node::GetName ();

The main requirement is that we are trying to give a name to other objects than nodes.

>   2. Everything gets put into the same namespace, nodes or whatever;

Yes, the use-case we are trying to support here is that of a global namespace for objects.

>   3. There should be trace path support for node names, otherwise what's the
> point.

Good idea: /Names/xxx/...

> An intermediate possibility would be to put the names in the NodeList class. 
> That would make a lot of sense, conceptually, and avoid the need for each node
> to carry a name.

That does not seem very desirable because other objects than nodes want names.

I am fine with NameContainer patch provided that it is available at the src/core level, and that we keep the existing std::string names in the NetDevice.  In particular, implement also:
Ptr<NetDevice> Node::GetDeviceByName (std::string name);

I feel that NetDevice are a special case because it would be nice to be able to reuse common strings for these across nodes, such as "eth0".

And I am fine with removing names from Channel and making those objects use the name container.

Created attachment 317 [details]
Simple bimap for name/object association plus use in csma-one-subnet.cc

Here's a quick and dirty NameList to address bug 215.  Even as simple as it is, it makes some code much more readable.  It is not completely integrated, though,

For example, there are new device helper methods that look like

  CsmaHelper::EnablePcap (std::string filename, std::string devname)

and you use them like

  CsmaHelper::EnablePcap ("csma-one-subnet", "Node0/eth0");

the problem is that the pcap trace file still has a file name that looks like,

  csma-one-subnet-0-0.pcap

which kindof defeats the high level purpose of naming.  We should really create files that reflect the names given in the script,

  csma-one-subnet-Node0-eth0 

I'm sure there's much more that needs to be done, but this patch provides basic naming.

Craig is going to investigate the following:

1) indirect the proposed Node::GetDeviceByName (std::string name) through the NameList, allowing for non-unique names such as "eth0", and remove the private std::string in class NetDevice (also remove the channel name).

2) try to prototype whether these names could also be used in the config subsystem

There are additionally some API issues regarding how we expose this at the helper API level, beyond whether the names exist also in the config namespace.  For instance, one can conceive of a CsmaHelper that, by default or by explicit configuration, adds an "eth" or "csm" prefix name to all devices when created, and does the right thing to assign "eth0" "eth1" (or "csm0" "csm1") in order, so that later, a user would have the expectation that if there is one CSMA device on the node, it must be "csm0"

Created attachment 356 [details]
Proposed object name service

This is a proposed addition for ns-3.4 -- an object name service.

Comment on attachment 356 [details]
Proposed object name service

Proposed bits now in repo craigdo/ns-3-names