Skip to main content

Module discovery

Module discovery 

Source
Expand description

Client-side node discovery (#936): read + select the active node set from CapacityBond.getRegisteredNodes, then rank probed blob-holders. Client-side node discovery (#936): read the active node set from CapacityBond.getRegisteredNodes so a client can pick a node instead of being handed an explicit --node-id/--addr/--provider-address. Read from fetch::discover_provider and from the discovery branch of bundle_pull::bundle_pull; the ranking half is also used by fetch::probe_and_rank. decdn probe deliberately still requires an explicit target.

This is the read + select half, plus the peer store that backs it up. Dialing the chosen node uses its iroh NodeId on a discovery-enabled endpoint (presets::N0 / configured [network.discovery]), and the registry’s NodeInfo.multiaddrs ride along as iroh direct-address hints (NodeCandidate::dial_addrs, with_dial_addrs): a reachable node then connects without a relay, while discovery and the relay path stay as the fallback for a node behind NAT (ADR 001 § Node Discovery). The hints are additive — a stale or malformed address loses the path race but never fails a dial.

bootstrap_nodes is the entry point: it wraps the registry read in ADR 012’s retry schedule and refreshes the [crate::PeerStore] identity records under the client data dir on success, falling back to the store’s surviving identities when the registry cannot be read. The store — one JSON file per peer under <data_dir>/peers — is the only filesystem state this module owns.

Structs§

NodeCandidate
A node the client may fetch from, distilled from a registry NodeInfo. Dialing is by node_id; the registry-published multiaddrs ride along as iroh direct-address hints so a reachable peer connects without a relay (see module docs and NodeCandidate::dial_addrs).
Probed
A probed candidate that holds the blob, with its measured RTT.

Enums§

Bootstrap
Where a bootstrap peer set came from.

Constants§

BOOTSTRAP_UNREACHABLE
The outermost context on a failed bootstrap — the wording pinned by ADR 012 § Bootstrap step 4. decdn’s error boundary renders {err:#} (sanitize_err_chain), so the user sees this sentence followed by the underlying cause chain.

Functions§

admit_sources
Pick up to max_sources candidates from an already-ranked ordered list, admitting at most ONE per eth_address (operator), without disturbing rank order. Used by the multi-source scheduler’s engagement gate to pick the source set for a parallel fetch — select_candidates/rank pick a single best node, this picks a set.
bootstrap_nodes
Bootstrap the client’s peer set (ADR 012 § Bootstrap): read the active node set from CapacityBond with the ADR’s retry schedule, refreshing the [crate::PeerStore] under data_dir on success and falling back to the store’s surviving identities when the registry cannot be read.
select_candidates
Pick candidates for probing (decision 3): shuffle, then same-region candidates first (equality on region_hint — locality, not geo distance), then the rest, capped at k. When client_region is None, empty, or not an accepted region code the region-first ordering is skipped and the result is a uniform random sample of k.
with_dial_addrs
Attach a candidate’s registry-published direct addresses to target as iroh direct-address hints (ADR 001 § Node Discovery), so a reachable peer connects without a relay. Additive: an empty or malformed multiaddrs field adds nothing and leaves iroh discovery and the relay fallback untouched, so this can only speed or enable a dial, never fail one.