Struct lightning::routing::network_graph::NetGraphMsgHandler [−][src]
pub struct NetGraphMsgHandler<C: Deref, L: Deref> where
C::Target: Access,
L::Target: Logger, { pub network_graph: RwLock<NetworkGraph>, // some fields omitted }
Expand description
Receives and validates network updates from peers, stores authentic and relevant data as a network graph. This network graph is then used for routing payments. Provides interface to help with initial routing sync by serving historical announcements.
Fields
network_graph: RwLock<NetworkGraph>
Representation of the payment channel network
Implementations
Creates a new tracker of the actual state of the network of channels and nodes, assuming a fresh network graph. Chain monitor is used to make sure announced channels exist on-chain, channel data is correct, and that the announcement is signed with channel owners’ keys.
pub fn from_net_graph(
chain_access: Option<C>,
logger: L,
network_graph: NetworkGraph
) -> Self
pub fn from_net_graph(
chain_access: Option<C>,
logger: L,
network_graph: NetworkGraph
) -> Self
Creates a new tracker of the actual state of the network of channels and nodes, assuming an existing Network Graph.
Adds a provider used to check new announcements. Does not affect existing announcements unless they are updated. Add, update or remove the provider would replace the current one.
Take a read lock on the network_graph and return it in the C-bindings
newtype helper. This is likely only useful when called via the C
bindings as you can call self.network_graph.read().unwrap()
in Rust
yourself.
Trait Implementations
impl<C: Deref, L: Deref> MessageSendEventsProvider for NetGraphMsgHandler<C, L> where
C::Target: Access,
L::Target: Logger,
impl<C: Deref, L: Deref> MessageSendEventsProvider for NetGraphMsgHandler<C, L> where
C::Target: Access,
L::Target: Logger,
impl<C: Deref, L: Deref> RoutingMessageHandler for NetGraphMsgHandler<C, L> where
C::Target: Access,
L::Target: Logger,
impl<C: Deref, L: Deref> RoutingMessageHandler for NetGraphMsgHandler<C, L> where
C::Target: Access,
L::Target: Logger,
Initiates a stateless sync of routing gossip information with a peer using gossip_queries. The default strategy used by this implementation is to sync the full block range with several peers.
We should expect one or more reply_channel_range messages in response to our query_channel_range. Each reply will enqueue a query_scid message to request gossip messages for each channel. The sync is considered complete when the final reply_scids_end message is received, though we are not tracking this directly.
fn handle_reply_channel_range(
&self,
their_node_id: &PublicKey,
msg: ReplyChannelRange
) -> Result<(), LightningError>
fn handle_reply_channel_range(
&self,
their_node_id: &PublicKey,
msg: ReplyChannelRange
) -> Result<(), LightningError>
Statelessly processes a reply to a channel range query by immediately sending an SCID query with SCIDs in the reply. To keep this handler stateless, it does not validate the sequencing of replies for multi- reply ranges. It does not validate whether the reply(ies) cover the queried range. It also does not filter SCIDs to only those in the original query range. We also do not validate that the chain_hash matches the chain_hash of the NetworkGraph. Any chan_ann message that does not match our chain_hash will be rejected when the announcement is processed.
fn handle_reply_short_channel_ids_end(
&self,
their_node_id: &PublicKey,
msg: ReplyShortChannelIdsEnd
) -> Result<(), LightningError>
fn handle_reply_short_channel_ids_end(
&self,
their_node_id: &PublicKey,
msg: ReplyShortChannelIdsEnd
) -> Result<(), LightningError>
When an SCID query is initiated the remote peer will begin streaming gossip messages. In the event of a failure, we may have received some channel information. Before trying with another peer, the caller should update its set of SCIDs that need to be queried.
fn handle_query_channel_range(
&self,
their_node_id: &PublicKey,
msg: QueryChannelRange
) -> Result<(), LightningError>
fn handle_query_channel_range(
&self,
their_node_id: &PublicKey,
msg: QueryChannelRange
) -> Result<(), LightningError>
Processes a query from a peer by finding announced/public channels whose funding UTXOs are in the specified block range. Due to message size limits, large range queries may result in several reply messages. This implementation enqueues all reply messages into pending events. Each message will allocate just under 65KiB. A full sync of the public routing table with 128k channels will generated 16 messages and allocate ~1MB. Logic can be changed to reduce allocation if/when a full sync of the routing table impacts memory constrained systems.
Handle an incoming node_announcement message, returning true if it should be forwarded on, false or returning an Err otherwise. Read more
fn handle_channel_announcement(
&self,
msg: &ChannelAnnouncement
) -> Result<bool, LightningError>
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. Read more
Handle some updates to the route graph that we learned due to an outbound failed payment.
Handle an incoming channel_update message, returning true if it should be forwarded on, false or returning an Err otherwise. Read more
fn get_next_channel_announcements(
&self,
starting_point: u64,
batch_amount: u8
) -> Vec<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)>ⓘ
fn get_next_channel_announcements(
&self,
starting_point: u64,
batch_amount: u8
) -> Vec<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)>ⓘ
Gets a subset of the 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 the batch_amount entries immediately higher in numerical value than starting_point. Read more
Gets a subset of the node announcements required to dump our routing table to a remote node,
starting at the node after the provided publickey and including batch_amount entries
immediately higher (as defined by
fn handle_query_short_channel_ids(
&self,
_their_node_id: &PublicKey,
_msg: QueryShortChannelIds
) -> Result<(), LightningError>
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. Read more