5 - Creating Custom RTI Managers

One powerful way of customizing the RTI's implementation through the plug-in API is by subclassing one or more of the RTI's managers, overriding appropriate functions, and then telling the RTI to instantiate your subclass instead of the default implementation of the manager.

Regardless of which manager you want to override, when subclassing any of the managers, the procedure is similar:

1. Include a static creator function that returns a new'ed instance of your subclass:

   class MyInterMgr : public DtInteractionMgr
   {
   public:
      // Creator function 
      static DtInteractionMgr* create(DtFederateMgr* fedMgr, 
         DtFomClassMgr* fom, DtRIDParameters* params) 
      { 
         return new MyInterMgr(fedMgr); 
      }
      // Provide the constructor and override the functions you choose 
   };

2. Within SetPluginCreators(), register your subclass's creator function with the RTI using the manager's static setCreatorFunction():

   // Register your new manager subclass's creator function with the RTI
   DtInteractionManager::setCreatorFunction(MyInterMgr::create);

When it is time for the RTI to instantiate an interaction manager, it will use your create function, which will result in the creation of a MyInterMgr instance. All of the managers have similar setCreatorFunction() member functions.

Note

The setInternalCreatorFunction() is used internally by the RTI. It should not be used by plug-ins, because the assignment might be overridden internally. Use the setCreatorFunction().

When you derive from the MAK RTI's managers, it is important to understand that the RTI itself sometimes uses subclasses of DtInteractionMgr, DtObjectMgr, and DtConnectionMgr rather than using those base classes directly. Therefore, if you need to extend or override default functionality you may need to derive from the RTI's subclasses rather than directly from these base manager classes.

Specifically, if DDM is disabled, the RTI uses DtObjectMgr and DtInteractionMgr. If DDM is enabled, it uses DtObjectDataDistMgr (objDdmMgr.h) and DtInterDataDistMgr (interDdmMgr.h) plus a derived class specific to the HLA specification (for example, DtObjectDataDistMgr13 (objDdmMgr13.h) and DtInterDataDistMgr13 (interDdmMgr13.h). Similar classes exist for the 1516 specifications. If your federation uses DDM, you should derive from one of the classes for the HLA specificaiton that you are using.

Similarly, the RTI normally uses an instance of DtAsyncConnectionMgr (asyConMgr.h), rather than the base DtConnectionMgr. (DtAsyncConnectionMgr adds to DtConnectionMgr the ability to handle asynchronous I/O.) If you want to extend or alter the connection manager while preserving the ability to handle asynchronous I/O, derive your class from DtAsyncConnectionMgr rather than from the base DtConnectionMgr.

[<< Monitoring RTI Service Invocations] [Home] [Top of Page] [Subclassing DtRtiAmbassadorImplementor >>]