|
Dynamic Routing Guide
|
See Example Protocol Files for the protocol buffer definition files.
The different message types are:
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.
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:
then it can simply access the binary fields directly. However, if it sees:
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 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).
There are three places in the DRO configuration file that Daemon Statistics are configured:
Here is an example of configuring daemon statistics.
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.
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).
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.
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>".
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>:
REQUEST TYPES ENABLED BY <remote-config-changes-request>:
mallinfo 5ri 5gcfg 5"G1-TRD1" pstat 5"G1-TRD1" pcfg 5