pub struct EventNotificationCounters {Show 15 fields
pub notification_class_missing: u64,
pub recipient_list_unavailable: u64,
pub recipient_list_invalid: u64,
pub recipient_list_too_long: u64,
pub device_recipient_unbound: u64,
pub recipient_unroutable: u64,
pub confirmed_broadcast_recipient: u64,
pub confirmed_no_invoke_id: u64,
pub confirmed_rejected: u64,
pub confirmed_unanswered: u64,
pub unconfirmed_send_failed: u64,
pub apdu_too_large: u64,
pub received_not_forwarded: u64,
pub forwarding_cap_dropped: u64,
pub received_not_logged: u64,
}Expand description
Lifetime totals of event notifications that were not delivered, each
saturating at u64::MAX. A new server starts at zero, and the totals stay
readable after stop(). Fields are sampled independently, not as one
atomic aggregate. Each refusal also logs a warning (the forwarding cap’s
at most once a minute); these totals are the
running signal, not an audit log.
The first four count transitions (event or acknowledgment notifications) whose Notification Class lookup failed closed, so no recipient received them. A class whose list is empty, or whose destinations all filter the transition out by day, time or transition, is configured behaviour and is not counted. Neither are notifications held back by DeviceCommunicationControl or Event_Enable; DCC holds a confirmed one back at a retry too, ending it there uncounted.
The next three count destinations that matched the transition but were skipped while their route was resolved, once per destination: the rest of the transition’s destinations are still served. They are grouped by what fixes them: a Device recipient the server holds no current address for, a recipient that can never be routed as written, and a confirmed recipient at a broadcast or other group address. The warning logged with each skip names the finer reason.
The next three count confirmed notifications to one recipient that were never acknowledged.
The next one counts unconfirmed notifications whose send failed at the transport, once per destination. The transition’s other destinations are still served. There is no counter for a notification that fails to encode: the committed payload and message text are validated before the destinations are walked, so a well-formed transition always encodes, and the send loop only logs and skips if that invariant is ever broken.
The next three concern the Notification Forwarder objects (#1225): copies too large to send unsegmented, received notifications no forwarder took, and destinations past the cap on one notification’s copies (#1259).
The last one counts received notifications the Event Logs that collect them would have taken but for their source’s allowance (#1346).
Fields§
§notification_class_missing: u64No Notification Class object has the class number the event object names.
The class exists but reading its Recipient_List failed.
recipient_list_invalid: u64The class’s Recipient_List did not decode as a whole; no decodable prefix is routed.
recipient_list_too_long: u64The class serves more than
MAX_RECIPIENT_LIST_DESTINATIONS
destinations, which only a custom Notification Class object can do.
device_recipient_unbound: u64Device recipients skipped because the server has no current binding
for them: none was configured or observed, or the observed one has
expired, and looking for the device found none. Such a recipient’s
notification waits in its device’s queue for the I-Am a targeted
Who-Is asks for (#1368), behind any already waiting there; it counts
here once when the device stays silent past the APDU timeout (a
minute at most), or at once when no Who-Is may go out for it (within
a minute of one that drew nothing, or with 256 devices already being
looked for) or 1,024 notifications already wait. Both clear once the
device’s I-Am is observed again or a binding is configured. A
confirmed notification whose observed binding expires before a retry
ends at that retry, its invoke ID freed, and counts here rather than
in confirmed_unanswered (#1371).
recipient_unroutable: u64Recipients that cannot be routed as configured, so no binding or retry delivers them: a Device recipient whose identifier is not a Device object, or whose binding is unusable on this link, and an address that puts a MAC on the global broadcast network (65535), which names neither a broadcast nor one device.
confirmed_broadcast_recipient: u64Recipients configured for confirmed notifications at a broadcast
address (local, remote or global, the link’s own broadcast MAC
included), or at any other group address the link reports
(TransportPort::is_group_destination, such as a B/IP multicast
address, #1493). Clause 6.3 lets only unconfirmed requests be
broadcast, and sending one unconfirmed would drop the acknowledgment
the destination asks for. No invoke ID is reserved for them.
confirmed_no_invoke_id: u64Confirmed notifications not sent because no confirmed transaction could be reserved, normally because every invoke ID was in use. Reservations refused while the server stops are not counted.
confirmed_rejected: u64Confirmed notifications the recipient answered with an Error, Reject or Abort.
confirmed_unanswered: u64Confirmed notifications that drew no acknowledgment after the last retry, including attempts whose send failed locally.
unconfirmed_send_failed: u64Unconfirmed notifications the transport refused to send, one per
destination: a unicast, a broadcast or a routed send that returned an
error. Nothing is retried. Confirmed sends that fail locally count in
confirmed_unanswered instead.
apdu_too_large: u64Notifications not sent to one destination because their APDU is longer than the local APDU capacity; notifications are never sent segmented. A forwarded copy of a notification that arrived segmented is the usual case. The other destinations are still served.
received_not_forwarded: u64Received ConfirmedEventNotification and UnconfirmedEventNotification requests that decoded but that no Notification Forwarder object took. A confirmed one is still acknowledged. One sent by global broadcast, which forwarders ignore, and a retransmitted confirmed one, which is acknowledged without being offered to them again, are not counted.
forwarding_cap_dropped: u64Destinations a notification was not forwarded to because it already
had MAX_FORWARDED_DESTINATIONS copies on their way across this
device’s forwarders, one per destination dropped. Only copies that
would be sent take room, so a destination the loop rules refuse is
neither counted here nor against the cap. Destinations go in
forwarder order, then list order, so the ones dropped are the last.
A capped notification logs a warning at most once a minute,
process-wide, and at debug level otherwise.
received_not_logged: u64Received ConfirmedEventNotification and UnconfirmedEventNotification
requests not logged because their source had used its allowance of
RECEIVED_EVENT_LOG_RATE records
in the current second, one per notification whatever the number of
logs. Notifications no Event Log collects are not counted.