]> git.bitcoin.ninja Git - rust-lightning/blobdiff - lightning/src/ln/msgs.rs
Pass Init message to sync_routing_table method
[rust-lightning] / lightning / src / ln / msgs.rs
index 671f4211ccc6de7c27b02f5ab741226c3d82c53c..073637413a82630866f8c7b3681683c883658375 100644 (file)
@@ -830,22 +830,26 @@ pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvide
        /// 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);
+       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>;
+       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>;
+       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.
-       fn handle_query_channel_range(&self, their_node_id: &PublicKey, msg: &QueryChannelRange) -> Result<(), LightningError>;
+       /// 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.
-       fn handle_query_short_channel_ids(&self, their_node_id: &PublicKey, msg: &QueryShortChannelIds) -> Result<(), LightningError>;
+       /// 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 {