SURVIVOR: Transport Module Specification

Specification

  1. Transport modules must be reentrant. That is, if a transport module is run more than once simultaneously, all instances must run to completion without interference.

  2. Transport modules must not change their process group by any means, including via setsid(), setpgid(), setpgrp(), or any similar function.

  3. Transport modules must handle their own parallelization. If a module is passed more than one host name to connect to, it is up to the module to determine the best way to handle it.

  4. Each module must place its source code in a directory underneath survivor/src/modules/transport/ with the following conventions:
    1. The name of the directory must be transport/modulename/.

    2. A Makefile.in must be present, with directives for clean, veryclean, all, install, and install-remote.

      The install should, except in exceptional circumstances, install the module into @prefix@/mod/transport, owned by @INST_USER@ and @INST_GROUP@, mode 555.

      The install-remote directive should be the same as install, except where it does not make sense for the module to be installed as part of a remote distribution. (Transport modules typically do not need to be installed remotely.)

    3. Documentation describing the module should be in doc/tm-modulename.html

  5. Transport modules must accept the following arguments:
    • -v
      A flag indicating the module should validate its configuration. The module must test for any dependencies (executables, libraries, modules, configuration files, etc) required for normal successful execution. If valid, exit with MODEXEC_OK (using scalar value 0 and the string "Module OK" as the comment, where Module is the name of the module), otherwise exit with MODEXEC_PROBLEM, following the output format specification described below.

  6. Transport modules receive the rest of their data via a SurvivorTransportData document, where

    • Host
      Host to perform the check on. Absence of this argument should cause the transport module to exit immediately with an appropriate return code.

    • Timeout
      The timeout for this module. After timeout seconds, the transport module may be gracelessly terminated. The transport module may use this timeout value to exit gracefully before time expires. If this option is not provided, the module may act as if there is no timeout.

    • ModuleOption
      The names and values of the arguments provided in check.cf. This element should conform to the Module XML Argument Specification.

    • RemoteModule
      • Module
        The remote module to execute, as specified in the configuration files.

      • ModType
        The type of remote module, as supported by the remote gateway. This argument is provided automatically by the system.

      • ModuleOption
        The names and values of the remote module arguments provided in check.cf or dependency.cf. This element should conform to the Module XML Argument Specification.

  7. Transport modules should not write output files.

  8. Transport modules must generate output compliant with the appropriate specification for the type of module being executed remotely.

  9. Transport modules must exit with a return code compliant with the appropriate specification for the type of module being executed remotely.

$Date: 2006/11/20 00:08:46 $
$Revision: 0.7 $
 keywords