Dynamic Routing Guide

DRO Binary Daemon Statistics

Note
  The C-style binary structure format of daemon statistics is DEPRECATED and may be removed in a future release. Informatica requests that users migrate to protobuf-based format. See Monitoring UM Daemons.

See Example Protocol Files for the protocol buffer definition files.

# DRO Daemon Statistics Structures <-

Note
  the C-style binary structure format of daemon statistics is DEPRECATED and may be removed in a future release. Informatica requests that users migrate to protobuf-based format. See Monitoring UM Daemons.

The different message types are:

- TNWG_DSTATTYPE_MALLINFO
- TNWG_DSTATTYPE_GATEWAYCFG
- TNWG_DSTATTYPE_PORTCFG
- TNWG_DSTATTYPE_RM_LOCAL
- TNWG_DSTATTYPE_RM_PORTAL
- TNWG_DSTATTYPE_RM_OTHERGW
- TNWG_DSTATTYPE_RM_OTHERGW_NBR
- TNWG_DSTATTYPE_PORTSTAT

Each one has a specific structure associated with it, as detailed in the file tnwgdmonmsgs.h.

Note that message types ending with "CFG" are in the config category. All others are in the stats category. See Daemon Statistics Structures for information on how the two categories are handled differently.

## DRO Daemon Statistics Byte Swapping <-

Note
  the C-style binary structure format of daemon statistics is DEPRECATED and may be removed in a future release. Informatica requests that users migrate to protobuf-based format. See Monitoring UM Daemons.

A monitoring application receiving these messages must detect if there is an endian mismatch (see Daemon Statistics Binary Data). The header structure tnwg_dstat_msg_hdr_t contains a 16-bit field named `magic` which is set equal to LBM_TNWG_DAEMON_MAGIC. The receiving application should compare it to LBM_TNWG_DAEMON_MAGIC and LBM_TNWG_DAEMON_ANTIMAGIC. Anything else would represent a serious problem.

If the receiving app sees:

magic == LBM_TNWG_DAEMON_MAGIC

then it can simply access the binary fields directly. However, if it sees:

magic == LBM_TNWG_DAEMON_ANTIMAGIC

then most (but not all) binary fields need to be byte-swapped. See Example tnwgdmon.c for an example, paying special attention to the macros `COND_SWAPxx` (which conditionally swaps based on the magic test) and the functions `byte_swapXX()` (which performs the byte swapping).

## DRO Daemon Statistics String Buffers <-

Note
  the C-style binary structure format of daemon statistics is DEPRECATED and may be removed in a future release. Informatica requests that users migrate to protobuf-based format. See Monitoring UM Daemons.

DRO Daemon Statistics data structures sometimes contain string buffers. Strings in these data structures are always null-terminated. These messages are generally sent as fixed-length equal to the sizes of the structures, and therefore include all of the declared bytes of the string fields, even if the contained string uses fewer bytes than declared. For example, the structure tnwg_dstat_record_hdr_t contains the field tnwg_dstat_record_hdr_t_stct::portal_name which is a `char` array of size `TNWG_DSTAT_MAX_PORTAL_NAME_LEN`. If `portal_name` is set to "p1", then only 3 bytes of the buffer are used (including the null string terminator). However, all `TNWG_DSTAT_MAX_PORTAL_NAME_LEN` bytes will be sent in the TNWG_DSTATTYPE_RM_PORTAL message type.

Contrast this with Store Daemon Statistics String Buffers.

There are two exceptions to this rule: TNWG_DSTATTYPE_PORTCFG and TNWG_DSTATTYPE_GATEWAYCFG.

The TNWG_DSTATTYPE_PORTCFG message is of type tnwg_pcfg_stat_grp_msg_t and has the field tnwg_pcfg_stat_grp_msg_t_stct::data. This field is a variable-length string buffer which contains one or more null-terminated strings. The total length of the TNWG_DSTATTYPE_PORTCFG message is the sum of the length of its sub-structures plus the number of bytes of string data (characters plus string-terminating nulls). The number of strings in tnwg_pcfg_stat_grp_msg_t_stct::data is given by tnwg_pcfg_stat_grp_msg_t_stct::rechdr->num_options. The monitoring application must step through the string buffer that many times to find each string. For an example of how to do this, see Example tnwgdmon.c in the code following, "`case TNWG_DSTATTYPE_PORTCFG:`".

The TNWG_DSTATTYPE_GATEWAYCFG message is of type tnwg_dstat_gatewaycfg_msg_t and has the field tnwg_dstat_gatewaycfg_msg_t_stct::data. This field is a variable-length string buffer which contains exactly one null-terminated string. This string contains the entirety of the DRO's configuration file. The individual lines contain the normal line-ending character(s). The total length of the TNWG_DSTATTYPE_GATEWAYCFG message is the length of its sub-structure plus the number of bytes of string data (characters plus string-terminating nulls).

# DRO Daemon Statistics Configuration <-

Note
  the C-style binary structure format of daemon statistics is DEPRECATED and may be removed in a future release. Informatica requests that users migrate to protobuf-based format. See Monitoring UM Daemons.

There are three places in the DRO configuration file that Daemon Statistics are configured:

- The <daemon-monitor> element inside the <daemon> definition. Configures all aspects of the DRO Daemon Statistics feature, including publishing intervals.
- The <publishing-interval> element inside the <peer> definition. Configures only the publishing intervals on a peer portal basis.
- The <publishing-interval> element inside the <endpoint> definition. Configures only the publishing intervals on an endpoint portal basis.

Here is an example of configuring daemon statistics.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- G1 xml file- 2 endpoint portals -->
<tnw-gateway version="1.0">
<daemon>
...
<publishing-interval>
<group name="default" ivl="3"/>
<group name="gateway-config" ivl="120"/>
<group name="portal-config" ivl="120"/>
</publishing-interval>
<remote-snapshot-request allow="1"/>
<remote-config-changes-request allow="1"/>
</daemon>
<portals>
<endpoint>
<name>G1-TRD1</name>
...
<publishing-interval>
<group name="default" ivl="6"/>
<group name="gateway-config" ivl="120"/>
<group name="portal-config" ivl="120"/>
</publishing-interval>
</endpoint>
...
</portals>
</tnw-gateway>

In this example, all stats-type messages are (conditionally) published on a 3-second interval, except those of portal G1-TRD1, which are published (conditionally) on a 6-second interval. All config-type messages are published (unconditionally) on a 120-second interval.

# DRO Daemon Control Requests <-

The DRO Daemon supports a monitoring application to send a specific set of requests to control the operation of Daemon Statistics. The <remote-snapshot-request> and <remote-config-changes-request> configuration elements control whether the DRO enables the Daemon Controller operation (defaults to disabled).

Warning
  If misused, the Daemon Control Requests feature allows a user to interfere with the messaging infrastructure in potentially disruptive ways. By default, this feature is disabled. However, especially if you have enabled UMP Element "<remote-config-changes-request>", Informatica recommends Securing Daemon Control Requests.

If enabled, the monitoring application can send a command message to the DRO in the form of a topicless unicast immediate "request" message (see lbm_unicast_immediate_request() with NULL for topic). The format of the message is a simple ascii string, with or without null termination. Due to the simple format of the message, no data structure is defined for it.

When the DRO receives and validates the command, it sends a UM response message back to the requesting application containing a status message (which is not null-terminated). If the status was OK, the DRO also performs the requested action.

## DRO Daemon Control Request Addressing <-

Since Daemon Control Requests are sent as UIM messages, you must use a target string to address the request to the desired DRO Process. The general form of a UIM target address is described in UIM Addressing, but is illustrated by this example:

    TCP:10.29.3.46:12009

where 10.29.3.46:12009 is the IP and Port of the Daemon Control context UIM port. These are typically configured using the request_tcp_interface (context) and request_tcp_port (context) options in the UM configuration file specified by the Router Element "<lbm-config>" contained within the Router Element "<daemon-monitor>".

## DRO Control Request Types <-

The example program Example tnwgdcmd.c demonstrates the correct way to send the messages and receive the responses.

REQUEST TYPES ENABLED BY <remote-snapshot-request>:

version
  The DRO returns in its command response the value of LBM_UMESTORE_DMON_VERSION. No daemon statistics messages are published.

snap mallinfo
  The DRO immediately publishes the memory allocation usage message of type TNWG_DSTATTYPE_MALLINFO.

snap pstat
  The DRO immediately publishes the portal statistics message(s) of type TNWG_DSTATTYPE_PORTSTAT.

snap ri
  The DRO immediately publishes the route information message(s) of types TNWG_DSTATTYPE_RM_LOCAL, TNWG_DSTATTYPE_RM_PORTAL TNWG_DSTATTYPE_RM_OTHERGW, and TNWG_DSTATTYPE_RM_OTHERGW_NBR.

snap gcfg
  The DRO immediately publishes the gateway configuration message TNWG_DSTATTYPE_GATEWAYCFG.

snap pcfg
  The DRO immediately publishes the portal configuration message(s) TNWG_DSTATTYPE_PORTCFG.

REQUEST TYPES ENABLED BY <remote-config-changes-request>:

mallinfo N
  Set the publishing interval for memory allocation usage.
  For example: `mallinfo 5`

ri N
  Set the publishing interval for the route information messages.
  For example: `ri 5`

gcfg N
  Set the publishing interval for the gateway configuration message.
  For example: `gcfg 5`

pstat N
  Set the publishing interval for the portal statistics messages. This command can be preceded by a portal name in double quote marks to only set the publishing interval for that portal.
  For example: `"G1-TRD1" pstat 5`

pcfg N
  Set the publishing interval for the portal configuration messages. This command can be preceded by a portal name in double quote marks to only set the publishing interval for that portal.
  For example: `"G1-TRD1" pcfg 5`