Struct MaelstromMeta 

pub struct MaelstromMeta {
    pub node_id: String,
    pub node_ids: Vec<String>,
    /* private fields */
}

Available on (crate features deploy or sim) and (crate features maelstrom_runtime or maelstrom) only.

Metadata for a Maelstrom node, populated from the init message. Also manages a shared stdin reader that broadcasts lines to multiple subscribers.

Fields

node_id: String

node_ids: Vec<String>

Implementations

impl MaelstromMeta

pub fn subscribe_stdin(&self) -> BroadcastStream<String>

Subscribe to stdin lines. Each subscriber receives all lines read from stdin. Multiple subscribers can be created and each will receive a copy of every line.

pub fn peers_ready(&self) -> Arc<AtomicBool>

A flag that becomes true once it is safe to send node-to-node messages.

Maelstrom sets up nodes concurrently: each node’s process is launched, registered in the simulated network, and sent init independently, with no barrier in between. A node that answers init quickly may therefore start sending to a peer whose process Maelstrom has not launched yet. Maelstrom treats a message to an unregistered destination as a fatal assertion failure (Invalid dest for message ...) and permanently stops reading the sender’s stdout, so every later response from that node (e.g. topology_ok) is silently lost and the test fails with Client read timeout.

Jepsen only opens clients after db/setup! (launch + init) has completed on every node, so receiving a client message proves all peers are registered. A message from a peer node proves the same thing transitively: peers also hold their outbound messages until they have been activated, so any peer message we receive was sent after some node observed a client message. Dropping outbound messages before activation is permitted because node-to-node channels in the Maelstrom backend are lossy.

pub fn start_receiving(&self)

Start receiving incoming messages from clients and other nodes, after launching the DFIR.