Dynamic Routing Guide
|
This section contains details on the UM Router's Daemon Statistics feature. You should already be familiar with the general information contained in Daemon Statistics.
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 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).
UM Router 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 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 UM Router'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 UM Router 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 UM Router 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 Store enables this request feature (defaults to disabled).
If enabled, the monitoring application can send a command message to the UM Router 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 UM Router 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 Store also performs the requested action.
The example program tnwgdcmd.c demonstrates the correct way to send the messages and receive the responses.
Commands enabled by <remote-snapshot-request>:
Commands enabled by <remote-config-changes-request>:
mallinfo 5
ri 5
gcfg 5
"G1-TRD1" pstat 5
"G1-TRD1" pcfg 5