From 7a4a29ffe0dbfdd2fe82376024ae680401c74700 Mon Sep 17 00:00:00 2001 From: bmancini55 Date: Thu, 3 Dec 2020 12:00:36 -0500 Subject: [PATCH] Pass Init message to sync_routing_table method This commit modifies sync_routing_table in RoutingMessageHandler to accept a reference to the Init message received by the peer. This allows the method to use the Peer's features to drive the operations of the gossip_queries routing table sync. --- lightning-net-tokio/src/lib.rs | 2 +- lightning/src/ln/msgs.rs | 2 +- lightning/src/routing/network_graph.rs | 46 +++++++++++++++++--------- lightning/src/util/test_utils.rs | 2 +- 4 files changed, 33 insertions(+), 19 deletions(-) diff --git a/lightning-net-tokio/src/lib.rs b/lightning-net-tokio/src/lib.rs index a90d673b6..eb4d347e6 100644 --- a/lightning-net-tokio/src/lib.rs +++ b/lightning-net-tokio/src/lib.rs @@ -536,7 +536,7 @@ mod tests { fn get_next_channel_announcements(&self, _starting_point: u64, _batch_amount: u8) -> Vec<(ChannelAnnouncement, Option, Option)> { Vec::new() } fn get_next_node_announcements(&self, _starting_point: Option<&PublicKey>, _batch_amount: u8) -> Vec { Vec::new() } fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool { false } - fn sync_routing_table(&self, _their_node_id: &PublicKey) { } + fn sync_routing_table(&self, _their_node_id: &PublicKey, _init_msg: &Init) { } fn handle_reply_channel_range(&self, _their_node_id: &PublicKey, _msg: ReplyChannelRange) -> Result<(), LightningError> { Ok(()) } fn handle_reply_short_channel_ids_end(&self, _their_node_id: &PublicKey, _msg: ReplyShortChannelIdsEnd) -> Result<(), LightningError> { Ok(()) } fn handle_query_channel_range(&self, _their_node_id: &PublicKey, _msg: QueryChannelRange) -> Result<(), LightningError> { Ok(()) } diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs index 8cd3f8acc..073637413 100644 --- a/lightning/src/ln/msgs.rs +++ b/lightning/src/ln/msgs.rs @@ -830,7 +830,7 @@ 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. diff --git a/lightning/src/routing/network_graph.rs b/lightning/src/routing/network_graph.rs index 48900ecc4..3a7cd4eb9 100644 --- a/lightning/src/routing/network_graph.rs +++ b/lightning/src/routing/network_graph.rs @@ -23,7 +23,7 @@ use bitcoin::hash_types::BlockHash; use chain; use chain::Access; use ln::features::{ChannelFeatures, NodeFeatures}; -use ln::msgs::{DecodeError, ErrorAction, LightningError, RoutingMessageHandler, NetAddress, MAX_VALUE_MSAT}; +use ln::msgs::{DecodeError, ErrorAction, Init, LightningError, RoutingMessageHandler, NetAddress, MAX_VALUE_MSAT}; use ln::msgs::{ChannelAnnouncement, ChannelUpdate, NodeAnnouncement, OptionalField}; use ln::msgs::{QueryChannelRange, ReplyChannelRange, QueryShortChannelIds, ReplyShortChannelIdsEnd}; use ln::msgs; @@ -226,7 +226,10 @@ impl RoutingMessageHandler for N /// 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 sync_routing_table(&self, their_node_id: &PublicKey) { + fn sync_routing_table(&self, their_node_id: &PublicKey, init_msg: &Init) { + if !init_msg.features.supports_gossip_queries() { + return (); + } let first_blocknum = 0; let number_of_blocks = 0xffffffff; log_debug!(self.logger, "Sending query_channel_range peer={}, first_blocknum={}, number_of_blocks={}", log_pubkey!(their_node_id), first_blocknum, number_of_blocks); @@ -996,9 +999,9 @@ impl NetworkGraph { #[cfg(test)] mod tests { use chain; - use ln::features::{ChannelFeatures, NodeFeatures}; + use ln::features::{ChannelFeatures, InitFeatures, NodeFeatures}; use routing::network_graph::{NetGraphMsgHandler, NetworkGraph}; - use ln::msgs::{OptionalField, RoutingMessageHandler, UnsignedNodeAnnouncement, NodeAnnouncement, + use ln::msgs::{Init, OptionalField, RoutingMessageHandler, UnsignedNodeAnnouncement, NodeAnnouncement, UnsignedChannelAnnouncement, ChannelAnnouncement, UnsignedChannelUpdate, ChannelUpdate, HTLCFailChannelUpdate, ReplyChannelRange, ReplyShortChannelIdsEnd, QueryChannelRange, QueryShortChannelIds, MAX_VALUE_MSAT}; use util::test_utils; @@ -1939,20 +1942,31 @@ mod tests { let chain_hash = genesis_block(Network::Testnet).header.block_hash(); let first_blocknum = 0; let number_of_blocks = 0xffff_ffff; - net_graph_msg_handler.sync_routing_table(&node_id_1); + + // It should ignore if gossip_queries feature is not enabled + { + let init_msg = Init { features: InitFeatures::known().clear_gossip_queries() }; + net_graph_msg_handler.sync_routing_table(&node_id_1, &init_msg); + let events = net_graph_msg_handler.get_and_clear_pending_msg_events(); + assert_eq!(events.len(), 0); + } // It should send a query_channel_message with the correct information - let events = net_graph_msg_handler.get_and_clear_pending_msg_events(); - assert_eq!(events.len(), 1); - match &events[0] { - MessageSendEvent::SendChannelRangeQuery{ node_id, msg } => { - assert_eq!(node_id, &node_id_1); - assert_eq!(msg.chain_hash, chain_hash); - assert_eq!(msg.first_blocknum, first_blocknum); - assert_eq!(msg.number_of_blocks, number_of_blocks); - }, - _ => panic!("Expected MessageSendEvent::SendChannelRangeQuery") - }; + { + let init_msg = Init { features: InitFeatures::known() }; + net_graph_msg_handler.sync_routing_table(&node_id_1, &init_msg); + let events = net_graph_msg_handler.get_and_clear_pending_msg_events(); + assert_eq!(events.len(), 1); + match &events[0] { + MessageSendEvent::SendChannelRangeQuery{ node_id, msg } => { + assert_eq!(node_id, &node_id_1); + assert_eq!(msg.chain_hash, chain_hash); + assert_eq!(msg.first_blocknum, first_blocknum); + assert_eq!(msg.number_of_blocks, number_of_blocks); + }, + _ => panic!("Expected MessageSendEvent::SendChannelRangeQuery") + }; + } } #[test] diff --git a/lightning/src/util/test_utils.rs b/lightning/src/util/test_utils.rs index 62bfda094..d1daf6bcd 100644 --- a/lightning/src/util/test_utils.rs +++ b/lightning/src/util/test_utils.rs @@ -320,7 +320,7 @@ impl msgs::RoutingMessageHandler for TestRoutingMessageHandler { self.request_full_sync.load(Ordering::Acquire) } - fn sync_routing_table(&self, _their_node_id: &PublicKey) {} + fn sync_routing_table(&self, _their_node_id: &PublicKey, _init_msg: &msgs::Init) {} fn handle_reply_channel_range(&self, _their_node_id: &PublicKey, _msg: msgs::ReplyChannelRange) -> Result<(), msgs::LightningError> { Ok(()) -- 2.39.5