• What Transport Modules Do
• Module Types
• Module Data
• Adding Custom Modules

Transport Modules are used by the scheduler to communicate with the remote gateway, to allow other modules to be executed directly on the host being monitored.

Like Check Modules, Transport Modules may be either compiled or scripted. However, unlike Check Modules, Transport Modules only run on the scheduler host.

Transport Modules are provided an XML document containing a SurvivorTransportData document.

Modules generate results in accordance with the remote module type being execute.

All Transport Modules must conform to the Transport Module Specification, otherwise they may not interact correctly with the scheduler.

It is important for Transport Modules to be properly parallelized, to prevent one non-responsive host from interfering with the checking of other hosts. There are two methods for easy parallelization:

1. libcm
   Compiled C++ modules may be built to use libcm, a multithreaded library to parallelize checking. Since Transport Modules are really just a special type of Check Module, use of the object interface as defined in include/libcm.H may be helpful.

2. Survivor.pm and Survivor/Check.pm
   Perl modules may be written against Survivor.pm and the related Survivor/Check.pm modules, which can detect if they are running under a multithreaded version of Perl, and can automatically parallelize via fork if threads are not available. Again, since Transport Modules are just a special type of Check Module, these routines may be useful.

   For information on these modules, run

        % perldoc src/modules/common/Survivor.pm
        % perldoc src/modules/common/Survivor/Check.pm
        

Transport Modules may require their arguments to be typed, using the same argument type specification as Check Module arguments.

For assistance in testing Transport Modules, the XML Maker utility may be useful.

Important: Please see the license for this package to see if custom modules are subject to the same license.