10 - rtiexec Plug-ins

In addition to customizing the behavior of the LRCs, you may need to customize the rtiexec.

For example, if you develop a plug-in that changes the wire format of the RTI or alters the communication mechanism used, you will also want to have the plug-in affect the rtiexec, so that it knows how to send, receive, or interpret according to the new scheme. Another reason to build an rtiexec plug-in is to monitor the federation. For example, you might want to have some code execute whenever federates join or leave the federation execution.

As previously discussed in Initializing a Plug-in, you initialize an rtiexec plug-in with InitRtiexecPlugin(). The object passed to InitRtiexecPlugin() is a DtRtiExec pointer. DtRtiExec (exec.h) is the top-level object that implements the rtiexec's functionality.

The DtRtiExec processes create and destroy messages from LRCs and maintain a list of DtFedExec objects, one for each active federation execution. You can get a pointer to this list using DtRtiExec::executionList(). DtFedExec (fedex.h) manages joins, resigns, and synchronization points for a particular federation execution. It manages a list of DtFederate objects (federate.h), one per federate, that is joined to the federation execution. You can get a pointer to this list using DtFedExec::federates(). You can use member functions on DtRtiExec, DtFedExec, and DtFederate to query these objects for information about current state. The classes also support callback mechanisms that allow a plug-in to be notified when federation executions are created or destroyed, when federates join or resign, and so on. For details, please see the appropriate header files.

The rtiexec uses an instance of DtConnectionMgr to manage its connections to the various LRCs. This is the same class used by the LRCs themselves. To change the communication mechanism used by the rtiexec, follow the same process you would use for the LRCs. That is, subclass DtConnectionMgr with a version that configures your DtRtiConnections appropriately, and then make sure that your version of DtConnectionMgr gets used by registering a creator function for it within your plug-in's SetPluginCreators() implementation.

To customize the behavior of the rtiexec, you might want to subclass DtRtiExec, DtFedExec, or DtFederate, and override some of its virtual functions. Of course you will need to tell the rtiexec to uses instances of your subclasses. To install your subclasses, call DtRtiExec::setCreatorFunction(), DtFedexec:setCreatorFunction(), or DtFederate::setCreatorFunction() from within your SetPluginCreators() function. Pass to these calls a static function that returns a new'ed instance of your subclass. The procedure is similar to creating custom managers, described in Creating Custom RTI Managers.

[<< Finding Out when Data is Available to be Read] [Home] [Accessing RID File Parameters >>]