2.3.1 Component system

The ns-3 component system is motivated in strong part by a recognition that a common use case for ns-2 has been the use of polymorphism to extend protocol models. For instance, specialized versions of TCP such as RenoTcpAgent derive from (and override functions from) class TcpAgent.

However, two problems that have arisen in the ns-2 model are downcasts and ``weak base class.'' Downcasting refers to the procedure of using a base class pointer to an object and querying it at run time to find out type information, used to explicitly cast the pointer to a subclass pointer so that the subclass API can be used. Weak base class refers to the problems that arise when a class cannot be effectively reused (derived from) because it lacks necessary functionality, leading the developer to have to modify the base class and causing proliferation of base class API calls, some of which may not be semantically correct for all subclasses.

ns-3 is using a version of the query interface design pattern to avoid these problems. This design is based on elements of the Component Object Model design^2.1 and GNOME Bonobo,^2.2although full binary-level compatibility of replaceable components is not supported and we have tried to simplify the syntax and impact on model developers. The aspects of COM that we are using provide:

• a component-oriented programming model, based on separation of interface and implementation. Interface objects are what client code uses to talk to the underlying implementation. When the class design follows this pattern, it allows components supporting similar interfaces to be swapped out.
• what if interfaces of replaceable components are not the same? COM provides a QueryInterface capability which, in our implementation, provides a type-safe way to query whether an object has a given capability or interface. The key to this architecture is that interfaces can be added or aggregated at run-time to objects without requiring rebuilding of the base classes, thereby avoiding weak base classes and the need for client-side C++ downcasts to provide run-time type information (RTTI).
• a system of unique identifiers for interfaces and classes.
• a component manager that is able to instantiate factories and objects themselves based on the identifiers mentioned above.
• a memory management policy rooted in reference counting.

We do not enforce the COM rule that interfaces are pure abstract and that one must separate the interface from implementation. A different, fuller port of COM to ns-3 was prototyped by Craig Dowell,^2.3 who initially suggested the use of COM concepts and implementation for ns-3.