Trait Resolver 

pub trait Resolver:
    Debug
    + Send
    + Sync
    + 'static {
    // Required method
    fn resolve<'a>(
        &'a self,
        exec: &'a Exec,
        name: &'a str,
        port: Option<u16>,
        max_addresses: usize,
    ) -> Resolved<'a>;
}

What a name means.

Implement this to answer a weida:// authority with whatever the deployment actually uses — DNS SRV, a service registry, the cloud provider’s API, or a table in a configuration file. The default is SystemResolver.

The contract

• Order matters. The addresses are dialled in the order returned, so a resolver that knows a preference expresses it by sorting. The caller tries the next one when a dial fails.
• port is the port the URL wrote, or None when it wrote none. None means the authority names a set (decisions/0020 §4.2), and it is the resolver that decides which ports that set listens on: the system resolver uses DEFAULT_PORT, an SRV resolver uses the ports the records carry.
• max_addresses is a cap, not a hint. A resolver answer is remote input, so returning more than asked for is a bug in the resolver (docs/INVARIANTS.md); the caller does not re-truncate.
• An empty answer is an error, not an empty set: a caller with no address has nothing to dial and deserves the reason.

The Exec

Resolution runs on the runtime the library was given, not on an ambient one: tokio::net::lookup_host needs a Tokio context, and a library that demanded its caller be inside one would be the mistake Exec exists to prevent. A resolver that spawns work does so through the handle it is passed.

Required Methods

fn resolve<'a>( &'a self, exec: &'a Exec, name: &'a str, port: Option<u16>, max_addresses: usize, ) -> Resolved<'a>

Resolves name into the addresses to dial, in order.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors

impl Resolver for SystemResolver