Message Relaying

← Back to Protocol Extensions and Quantum Signatures

---

Introduction

Efficient message propagation is essential for a decentralized ledger. Transactions must reach validators quickly, proposals must spread to enable consensus, and validations must propagate to finalize ledgers. The overlay network's message relaying system ensures information flows efficiently while preventing network overload through intelligent squelching.

This lesson explores how messages propagate through the network and how Rippled optimizes this process to handle high-throughput scenarios.

---

OverlayImpl::relay

OverlayImpl::relay(protocol::TMProposeSet& m, uint256 const& uid, PublicKey const& validator) (OverlayImpl.cpp):

• Calls app_.getHashRouter().shouldRelay(uid) to determine if the proposal should be relayed.

• If not, returns an empty set.

• If yes:

  • Creates a shared pointer to a Message object containing the proposal.

  • Iterates over all active peers.

  • For each peer not in the skip set, sends the proposal message.

• Returns the set of peer IDs that were skipped.

Slot::update and Squelch Mechanism

Slot::update (Slot.h):

• Tracks peer activity for a validator, incrementing message counts and considering peers for selection.

• When enough peers reach the message threshold, randomly selects a subset to be "Selected" and squelches the rest (temporarily mutes them).

• Squelched peers are unsquelched after expiration.

• Handles all state transitions, logging, and squelch/unsquelch notifications via the SquelchHandler interface.

OverlayImpl::unsquelch (OverlayImpl.cpp):

• Looks up the peer by short ID.

• If found, constructs a TMSquelch message with squelch=false for the validator.

• Sends the message to the peer, instructing it to stop squelching messages from the validator.

---