Struct UnsentCounts 

pub struct UnsentCounts {
    pub invite: u64,
    pub ack: u64,
    pub bye: u64,
    pub cancel: u64,
    pub other: u64,
}

Requests the endpoint tried to put on the wire and could not, by method (§12.3).

Split by method because the consequence is. A CANCEL that does not go out leaves the far end ringing; an ACK that does not go out leaves a 2xx retransmitting for thirty-two seconds and then a peer streaming at a port this side has closed; a BYE that does not go out leaves a dialog up at the far end that no timer will reap. One number would hide which of those happened, and they are the three questions an operator asking “why did that call linger” is choosing between.

Where this is counted, and why not at the hand-off

At the transmit, in the driver — the two places the socket is actually written: a transaction’s Output::Send, and the direct send that carries an ACK for a 2xx.

It was counted inside crate::Handle::send and crate::Handle::send_directly when X-54 first wrote it, and that was wrong in a way the type’s own documentation concealed. Handle::send returns as soon as the driver has created the transaction and handed back its key; the transmit happens afterwards. So a counter at that hand-off could only ever fire when the endpoint refused the request outright — a closed endpoint, or a request with no usable Via — and never on a refused connection, an unreachable peer or an over-MTU datagram, which is the whole of the question it claims to answer. send_directly did await the transmit, so ack behaved one way and bye and cancel another, with nothing saying so. Counting where the wire is missed makes all four mean the same thing.

What this does and does not promise (§12.2)

• Requests only. A response that fails to transmit is counted by DiscardCounts::send_failures and not here, because these fields are methods and a response has none.
• This overlaps DiscardCounts::send_failures on purpose, and the two are views rather than tallies. A request that fails on the transaction path increments both: that field is the transaction path’s aggregate over requests and responses alike, this is the per-method breakdown over requests on any path. Adding them together is meaningless, and so is subtracting them — §12.2’s rule against arithmetic across fields applies here in particular.
• An endpoint that is shutting down does not inflate this. A send that loses the race with shutdown fails at the hand-off, before any transmit is attempted, and is not counted — the earlier design counted it, which made an ordinary teardown look like lost signalling.

Fields

invite: u64

INVITEs the endpoint could not put on the wire.

ack: u64

ACKs the endpoint could not put on the wire — RFC 3261 §13.2.2.4’s ACK for a 2xx, which has no transaction to retry it.

bye: u64

BYEs the endpoint could not put on the wire. The one that leaves a call up at the far end.

cancel: u64

CANCELs the endpoint could not put on the wire. The one that leaves a phone ringing.

other: u64

Every other method the endpoint could not put on the wire.

Implementations

impl UnsentCounts

pub fn total(self) -> u64

Every request that did not reach the wire, of every method.

Trait Implementations

impl Clone for UnsentCounts

fn clone(&self) -> UnsentCounts

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for UnsentCounts

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for UnsentCounts

fn default() -> UnsentCounts

Returns the “default value” for a type.

impl PartialEq for UnsentCounts

fn eq(&self, other: &UnsentCounts) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for UnsentCounts

impl Eq for UnsentCounts

impl StructuralPartialEq for UnsentCounts