Pass Init message to sync_routing_table method

[rust-lightning] / lightning / src / ln / msgs.rs

diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index f57cf0fd1fb9304fac06f34fad5164e6e8a1dfe4..073637413a82630866f8c7b3681683c883658375 100644 (file)
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -804,7 +804,7 @@ pub trait ChannelMessageHandler : events::MessageSendEventsProvider + Send + Syn
 }
 
 /// A trait to describe an object which can receive routing messages.
-pub trait RoutingMessageHandler : Send + Sync {
+pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvider {
        /// Handle an incoming node_announcement message, returning true if it should be forwarded on,
        /// false or returning an Err otherwise.
        fn handle_node_announcement(&self, msg: &NodeAnnouncement) -> Result<bool, LightningError>;
@@ -827,6 +827,29 @@ pub trait RoutingMessageHandler : Send + Sync {
        fn get_next_node_announcements(&self, starting_point: Option<&PublicKey>, batch_amount: u8) -> Vec<NodeAnnouncement>;
        /// Returns whether a full sync should be requested from a peer.
        fn should_request_full_sync(&self, node_id: &PublicKey) -> bool;
+       /// Initiates routing gossip sync by querying a peer to discover channels
+       /// and their associated routing gossip messages. This method will use a
+       /// sync strategy defined by the implementor.
+       fn sync_routing_table(&self, their_node_id: &PublicKey, init: &Init);
+       /// 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_channel_range(&self, their_node_id: &PublicKey, msg: ReplyChannelRange) -> 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_reply_short_channel_ids_end(&self, their_node_id: &PublicKey, msg: ReplyShortChannelIdsEnd) -> Result<(), LightningError>;
+       /// Handles when a peer asks us to send a list of short_channel_ids
+       /// for the requested range of blocks. There are potential DoS vectors when
+       /// handling inbound queries. Handling requests with first_blocknum very far
+       /// away may trigger repeated disk I/O if the NetworkGraph is not fully in-memory.
+       fn handle_query_channel_range(&self, their_node_id: &PublicKey, msg: QueryChannelRange) -> Result<(), LightningError>;
+       /// Handles when a peer asks us to send routing gossip messages for a
+       /// list of short_channel_ids. There are potential DoS vectors when handling
+       /// inbound queries. Handling requests with first_blocknum very far away may
+       /// trigger repeated disk I/O if the NetworkGraph is not fully in-memory.
+       fn handle_query_short_channel_ids(&self, their_node_id: &PublicKey, msg: QueryShortChannelIds) -> Result<(), LightningError>;
 }
 
 mod fuzzy_internal_msgs {