UM C API 6.17.1

- Main Page
- Related Pages
- Modules
- Data Structures
- Files

- Data Structures
- Data Fields

Data Fields
lbm_rcv_transport_stats_lbtrm_t_stct Struct Reference

Structure that holds datagram statistics for receiver LBT-RM transports. More...

`#include <lbm.h>`

## Data Fields
lbm_ulong_t | msgs_rcved
| Number of LBT-RM datagrams received. (Cumulative) More...
lbm_ulong_t | bytes_rcved
| Number of LBT-RM datagram bytes received, i.e., the total of lengths of all LBT-RM packets including UM header information. (Cumulative) More...
lbm_ulong_t | nak_pckts_sent
| Number of NAK packets sent by the receiver transport. (Cumulative) More...
lbm_ulong_t | naks_sent
| Number of individual NAKs sent by the receiver transport. (Cumulative) More...
lbm_ulong_t | lost
| Number of LBT-RM datagrams detected as lost. (Cumulative) More...
lbm_ulong_t | ncfs_ignored
| Number of NCFs received from a source transport with reason code "ignored". (Cumulative) More...
lbm_ulong_t | ncfs_shed
| Number of NCFs received with reason code "shed". (Cumulative) More...
lbm_ulong_t | ncfs_rx_delay
| Number of NCFs received with reason code "rx_delay". (Cumulative) More...
lbm_ulong_t | ncfs_unknown
| Number of NCFs received with reason code "unknown". (Cumulative) More...
lbm_ulong_t | nak_stm_min
| Minimum time (in milliseconds), i.e., the shortest time recorded so far for a lost message to be recovered. (Cumulative) More...
lbm_ulong_t | nak_stm_mean
| Mean time (in milliseconds) in which loss recovery was accomplished. (Cumulative) More...
lbm_ulong_t | nak_stm_max
| Maximum time (in milliseconds), i.e., the longest time recorded so far for a lost message to be recovered. (Cumulative) More...
lbm_ulong_t | nak_tx_min
| Minimum number of times per lost message that a receiver transport transmitted a NAK, i.e., the lowest value collected so far. A value greater than 1 indicates a chronically lossy network. (Cumulative) More...
lbm_ulong_t | nak_tx_mean
| Mean number of times per lost message that a receiver transport transmitted a NAK. (Cumulative) More...
lbm_ulong_t | nak_tx_max
| Maximum number of times per lost message that a receiver transport transmitted a NAK, i.e., the highest value collected so far. (Cumulative) More...
lbm_ulong_t | duplicate_data
| Number of duplicate LBT-RM datagrams received. (Cumulative) More...
lbm_ulong_t | unrecovered_txw
| Number of LBT-RM datagrams unrecovered (LBM_MSG_UNRECOVERABLE_LOSS delivered to receiver application) due to transmission window advance. (Cumulative) More...
lbm_ulong_t | unrecovered_tmo
| Number of LBT-RM datagrams unrecovered due to a retransmission not received within the NAK generation interval (set by configuration option transport_lbtrm_nak_generation_interval (receiver); default 10,000ms). (Cumulative) More...
lbm_ulong_t | lbm_msgs_rcved
| Number of messages or message fragments received over an LBT-RM transport. (Cumulative) More...
lbm_ulong_t | lbm_msgs_no_topic_rcved
| Number of messages received that were not for a topic of interest to the receiver. (Cumulative) More...
lbm_ulong_t | lbm_reqs_rcved
| Number of UM request messages received (message type LBM_MSG_REQUEST). (Cumulative)
lbm_ulong_t | dgrams_dropped_size
| Number of datagrams discarded due to being smaller than the size designated in the datagram's size field. (Cumulative)
lbm_ulong_t | dgrams_dropped_type
| Number of datagrams discarded due to bad packet type. The datagram's type field must match the expectations of the receiver transport. (Cumulative)
lbm_ulong_t | dgrams_dropped_version
| Number of datagrams discarded due to version mismatch. The datagram's version field must match the expectations of the receiver transport. (Cumulative)
lbm_ulong_t | dgrams_dropped_hdr
| Number of datagrams discarded due to bad header type. These datagrams appeared to be intact, but with an unrecognizable header format. (Cumulative)
lbm_ulong_t | dgrams_dropped_other
| Number of unrecognizable datagrams discarded due to reasons other than those determined by the above counts. (Cumulative) More...
lbm_ulong_t | out_of_order
| Number of out-of-order LBT-RM transport datagrams received. (Cumulative) More...

## Detailed Description

Structure that holds datagram statistics for receiver LBT-RM transports.

Note that when stats are sampled, the fields in the structure are not necessarily from the same instant in time. The structure might be updated concurrently with it being sampled, and while each structure field is atomically read, the field values can be skewed slightly across time.

See lbm_rcv_transport_stats_lbtrm_t_stct for field definitions.

Cumulative vs Snapshot

These UM statistics are cumulative. For example, msgs_rcved starts at zero and grows over time as more and more messages are sent.

## Field Documentation

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::bytes_rcved

Number of LBT-RM datagram bytes received, i.e., the total of lengths of all LBT-RM packets including UM header information. (Cumulative)

This count does not include duplicate datagrams or datagrams rejected for some reason.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::dgrams_dropped_other

Number of unrecognizable datagrams discarded due to reasons other than those determined by the above counts. (Cumulative)

They could be corrupted, or possibly be from a non-UM packet source.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::duplicate_data

Number of duplicate LBT-RM datagrams received. (Cumulative)

A large number can indicate a lossy network, primarily due to other receiver transports requesting retransmissions that this receiver transport has already successfully received. Such duplicates require extra effort for filtering, and this should be investigated.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::lbm_msgs_no_topic_rcved

Number of messages received that were not for a topic of interest to the receiver. (Cumulative)

A high value (relative to, or approaching lbm_msgs_rcved above) indicates more CPU time required to filter out uninteresting topics, in which case, consider reconfiguring sources to filter more aggressively at the transport layer.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::lbm_msgs_rcved

Number of messages or message fragments received over an LBT-RM transport. (Cumulative)

A single datagram may contain one or more messages or a fragment of a larger message. For fragmented messages larger than configuration option transport_lbtrm_datagram_max_size (context) (default 8KB), this count reflects the number of datagrams used to constitute those messages. Thus, this number is equal to or greater than the datagram counter (msgs_rcved, above). This number also includes messages received for which there was no interested receiver, which is tallied in the lbm_msgs_no_topic_rcved counter (below).

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::lost

Number of LBT-RM datagrams detected as lost. (Cumulative)

Note that out-of-order network packets will also increment the lost count. See also out_of_order.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::msgs_rcved

Number of LBT-RM datagrams received. (Cumulative)

Depending on batching settings, a single LBT-RM datagram may contain one or more messages, or a fragment of a larger message. With LBT-RM, larger messages are split into fragment sizes limited by configuration option transport_lbtrm_datagram_max_size (context) (default 8KB).

This count does not include duplicate datagrams or datagrams rejected for any reason.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_pckts_sent

Number of NAK packets sent by the receiver transport. (Cumulative)

UM batches NAKs into NAK packets to save network bandwidth. This should always be less than or equal to the number of individual NAKs sent (naks_sent, below).

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_stm_max

Maximum time (in milliseconds), i.e., the longest time recorded so far for a lost message to be recovered. (Cumulative)

If this time is near or equal to the configuration option transport_lbtrm_nak_generation_interval (receiver) setting, you have likely experienced some level of unrecoverable loss.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_stm_mean

Mean time (in milliseconds) in which loss recovery was accomplished. (Cumulative)

This is an exponentially weighted moving average (weighted to more recent) for accumulated measured recovery times. Ideally this field should be as close to your minimum recovery time (nak_stm_min, above) as possible. High mean recovery times indicate a lossy network.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_stm_min

Minimum time (in milliseconds), i.e., the shortest time recorded so far for a lost message to be recovered. (Cumulative)

If this time is greater than configuration option transport_lbtrm_nak_backoff_interval (receiver), it may be taking multiple NAKs to initiate retransmissions, indicating a lossy network.

This field is initialized to all 1s (-1 if printed signed).

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_tx_max

Maximum number of times per lost message that a receiver transport transmitted a NAK, i.e., the highest value collected so far. (Cumulative)

A value higher than 1 suggests that there may have been some unrecoverable loss on the network during the sample period. A significantly high value (compared to the mean number) implies an isolated incident.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_tx_mean

Mean number of times per lost message that a receiver transport transmitted a NAK. (Cumulative)

Ideally this should be at or near 1. A higher value indicates a lossy network. This is an exponentially weighted moving average (weighted to more recent) for accumulated NAKs per lost message.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::nak_tx_min

Minimum number of times per lost message that a receiver transport transmitted a NAK, i.e., the lowest value collected so far. A value greater than 1 indicates a chronically lossy network. (Cumulative)

This field is initialized to all 1s (-1 if printed signed).

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::naks_sent

Number of individual NAKs sent by the receiver transport. (Cumulative)

This may differ from the tally of lost datagrams (below) due to reasons such as

- Other receiver transports may have already sent a NAK for the same lost datagram, resulting in a retransmitted lost datagram (or an NCF) to arrive at this receiver transport before it has a chance to issue a NAK, or
- During periods of heavy loss, receiver transports may be forced to issue multiple NAKs per lost datagram (controlled by configuration options transport_lbtrm_nak_generation_interval (receiver) and transport_lbtrm_nak_backoff_interval (receiver)) until either the retransmission is received or the datagram is declared unrecovered (which may ultimately lead to UM delivering an LBM_MSG_UNRECOVERABLE_LOSS notification to the receiver application).

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::ncfs_ignored

Number of NCFs received from a source transport with reason code "ignored". (Cumulative)

If a source transport receives a NAK for a datagram that it has recently retransmitted, it sends an "NCF ignored" and does not retransmit. How "recently" is determined by the configuration option source transport_lbtrm_ignore_interval (source) (default 500ms). If this count is high, a receiver transport may be having trouble receiving retransmissions, or the ignore interval may be set too long.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::ncfs_rx_delay

Number of NCFs received with reason code "rx_delay". (Cumulative)

When a source transport's retransmit rate limiter prevents it from immediately retransmitting any more lost datagrams, it responds to a NAK by sending an "NCF rx_delay", then queues the retransmission for a later send. The receiver transport should wait for the retransmission and not immediately send another NAK. If this count is high, one or more crybaby receiver transports may be clogging the source transport's retransmit queue.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::ncfs_shed

Number of NCFs received with reason code "shed". (Cumulative)

When a source transport's retransmit queue and rate limiter are both at maximum, it responds to a NAK by sending an "NCF shed", and does not retransmit. The receiver transport should wait, then send another NAK. If this count is high, one or more crybaby receiver transports may be clogging the source transport's retransmit queue.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::ncfs_unknown

Number of NCFs received with reason code "unknown". (Cumulative)

These are NCFs with a reason code this receiver transport does not recognize. After a delay (set by configuration option transport_lbtrm_nak_suppress_interval (receiver) (default 1000ms), it resends the NAK. This counter should never be greater than 0 unless applications linked with different versions of Ultra Messaging software coexist on the same network.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::out_of_order

Number of out-of-order LBT-RM transport datagrams received. (Cumulative)

A datagram is counted as out of order if it fills a previously detected sequence gap, but is not a retransmission. Note that out-of-order reception of datagrams also increments. the lost counter.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::unrecovered_tmo

Number of LBT-RM datagrams unrecovered due to a retransmission not received within the NAK generation interval (set by configuration option transport_lbtrm_nak_generation_interval (receiver); default 10,000ms). (Cumulative)

NOTE: Receivers for these messages' topics will also report related messages as unrecoverable, with LBM_MSG_UNRECOVERABLE_LOSS for an individual message and LBM_MSG_UNRECOVERABLE_LOSS_BURST for a burst loss event. However, it is possible for these application-level message declarations to occur even without increments to this counter, as the transport is unaware of the topic content of messages and may still be trying to deliver related lost packets.

lbm_ulong_t lbm_rcv_transport_stats_lbtrm_t_stct::unrecovered_txw

Number of LBT-RM datagrams unrecovered (LBM_MSG_UNRECOVERABLE_LOSS delivered to receiver application) due to transmission window advance. (Cumulative)

This means that the message was no longer in the source-side transmission window and therefore not retransmitted. The window size is set by transport configuration option transport_lbtrm_transmission_window_size (source) (default 24MB).

The documentation for this struct was generated from the following file:

- lbm.h