Skip to main content

Module strategy

Module strategy 

Source
Expand description

The traversal strategy — orders the enabled methods (direct-first, relay-last), tries each with a bounded timeout, and returns the FIRST connection that establishes. This is where “the caller doesn’t choose the method” is realised.

§Order

Methods are always attempted in TraversalKind::rank order — Direct → Upnp → NatPmp → Pcp → HolePunch → Relayed — regardless of the order the caller listed them, so the cheapest/most-direct path is preferred and the fully-relayed transport is genuinely the LAST resort.

§Two-stage attempt

A method yields a MethodOutcome (a dial address + which technique). The strategy then asks the Dialer to establish the mTLS session to that address. Both stages are bounded by the per-method timeout, so a hung method OR a hung dial can never block connect. If both stages fail for every method, the strategy returns NatError::AllMethodsFailed with the ordered per-method reasons.

§Testability

Dialer abstracts the mTLS dial (real impl in crate::dialer; tests inject a fake that returns a canned outcome), and the methods are TraversalMethod trait objects (tests inject mocks). So the ordering, first-success-wins, relay-last, and all-fail→error behaviour are all tested with NO real network.

Traits§

Dialer
Establishes the actual mTLS peer connection once a method has produced reachable address(es).

Functions§

connect_with_strategy
Run the traversal strategy: try each enabled method in rank order; the first that produces a verified mTLS PeerConnection wins. methods may be listed in any order — they are sorted by TraversalKind::rank here so ordering is guaranteed independent of caller input.