Struct breez_sdk_core::lightning::util::test_utils::TestRoutingMessageHandler

pub struct TestRoutingMessageHandler {
    pub chan_upds_recvd: AtomicUsize,
    pub chan_anns_recvd: AtomicUsize,
    pub pending_events: Mutex<Vec<MessageSendEvent>>,
    pub request_full_sync: AtomicBool,
}

Fields

chan_upds_recvd: AtomicUsize

chan_anns_recvd: AtomicUsize

pending_events: Mutex<Vec<MessageSendEvent>>

request_full_sync: AtomicBool

Implementations

impl TestRoutingMessageHandler

pub fn new() -> TestRoutingMessageHandler

Trait Implementations

impl MessageSendEventsProvider for TestRoutingMessageHandler

fn get_and_clear_pending_msg_events(&self) -> Vec<MessageSendEvent>

Gets the list of pending events which were generated by previous actions, clearing the list in the process.

impl RoutingMessageHandler for TestRoutingMessageHandler

fn handle_node_announcement( &self, _msg: &NodeAnnouncement, ) -> Result<bool, LightningError>

Handle an incoming node_announcement message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn handle_channel_announcement( &self, _msg: &ChannelAnnouncement, ) -> Result<bool, LightningError>

Handle a channel_announcement message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn handle_channel_update( &self, _msg: &ChannelUpdate, ) -> Result<bool, LightningError>

Handle an incoming channel_update message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn get_next_channel_announcement( &self, starting_point: u64, ) -> Option<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)>

Gets channel announcements and updates required to dump our routing table to a remote node, starting at the short_channel_id indicated by starting_point and including announcements for a single channel.

fn get_next_node_announcement( &self, _starting_point: Option<&NodeId>, ) -> Option<NodeAnnouncement>

Gets a node announcement required to dump our routing table to a remote node, starting at the node after the provided pubkey and including up to one announcement immediately higher (as defined by <PublicKey as Ord>::cmp) than starting_point. If None is provided for starting_point, we start at the first node.

fn peer_connected( &self, their_node_id: &PublicKey, init_msg: &Init, _inbound: bool, ) -> Result<(), ()>

Called when a connection is established with a peer. This can be used to perform routing table synchronization using a strategy defined by the implementor.

fn handle_reply_channel_range( &self, _their_node_id: &PublicKey, _msg: ReplyChannelRange, ) -> Result<(), LightningError>

Handles the reply of a query we initiated to learn about channels for a given range of blocks. We can expect to receive one or more replies to a single query.

fn handle_reply_short_channel_ids_end( &self, _their_node_id: &PublicKey, _msg: ReplyShortChannelIdsEnd, ) -> Result<(), LightningError>

Handles the reply of a query we initiated asking for routing gossip messages for a list of channels. We should receive this message when a node has completed its best effort to send us the pertaining routing gossip messages.

fn handle_query_channel_range( &self, _their_node_id: &PublicKey, _msg: QueryChannelRange, ) -> Result<(), LightningError>

Handles when a peer asks us to send a list of short_channel_ids for the requested range of blocks.

fn handle_query_short_channel_ids( &self, _their_node_id: &PublicKey, _msg: QueryShortChannelIds, ) -> Result<(), LightningError>

Handles when a peer asks us to send routing gossip messages for a list of short_channel_ids.

fn provided_node_features(&self) -> Features<NodeContext>

Gets the node feature flags which this handler itself supports. All available handlers are queried similarly and their feature flags are OR’d together to form the NodeFeatures which are broadcasted in our NodeAnnouncement message.

fn provided_init_features( &self, _their_init_features: &PublicKey, ) -> Features<InitContext>

Gets the init feature flags which should be sent to the given peer. All available handlers are queried similarly and their feature flags are OR’d together to form the InitFeatures which are sent in our Init message.

fn processing_queue_high(&self) -> bool

Indicates that there are a large number of ChannelAnnouncement (or other) messages pending some async action. While there is no guarantee of the rate of future messages, the caller should seek to reduce the rate of new gossip messages handled, especially ChannelAnnouncements.