Skip to main content

AddressableManager

commonware_p2p

Trait AddressableManager 

Source 
pub trait AddressableManager: Provider {
    // Required methods
    fn track<R>(&mut self, id: u64, peers: R) -> impl Future<Output = ()> + Send
       where R: Into<AddressableTrackedPeers<Self::PublicKey>> + Send;
    fn overwrite(
        &mut self,
        peers: Map<Self::PublicKey, Address>,
    ) -> impl Future<Output = ()> + Send;
}
Expand description

Interface for managing peer set membership (where peer addresses are known).

Required Methods§

Source

fn track<R>(&mut self, id: u64, peers: R) -> impl Future<Output = ()> + Send
where R: Into<AddressableTrackedPeers<Self::PublicKey>> + Send,

Track a primary peer set and secondary peers with the given ID.

The peer set ID passed to this function should be strictly managed, ideally matching the epoch of the consensus engine. It must be monotonically increasing as new peer sets are tracked.

For good connectivity, all peers must track the same peer sets at the same ID.

Callers may pass either a list of primary peers or a AddressableTrackedPeers value containing both primary and secondary peers.

The same key may appear in both maps; see AddressableTrackedPeers.

§Active Peers

The most recently registered peer set (highest ID) is considered the active set. Implementations use the active set to decide which peers to maintain connections with and which to disconnect from.

§Primary vs Secondary Peers

In p2p networks, there are often two tiers of peers: ones that help “drive progress” and ones that want to “follow that progress” (but not contribute to it). We call the former “primary” and the latter “secondary”. When both are tracked, mechanisms favor “primary” peers but continue to replicate data to “secondary” peers ( often both gossiping data to them and answering requests from them).

Source

fn overwrite( &mut self, peers: Map<Self::PublicKey, Address>, ) -> impl Future<Output = ()> + Send

Update addresses for multiple peers without creating a new peer set.

For each primary or secondary peer with a changed address:

  • Any existing connection to the peer is severed (it was on the old IP)
  • The listener’s allowed IPs are updated to reflect the new egress IP
  • Future connections will use the new address

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors§