Remove should_request_full_sync from RoutingMessageHandler

This method was used to set the initial_routing_sync flag when sending
an outbound Init message to a peer. Since we are now relying on
gossip_queries instead of initial_routing_sync, synchronization can be
fully encapsulate into RoutingMessageHandler via sync_routing_table.

This commit removes should_request_full_sync from the trait
RoutingMessageHandler. The implementation is still used in
NetGraphMsgHandler and has been converted into a private method instead
of a trait function.

diff --git a/lightning-net-tokio/src/lib.rs b/lightning-net-tokio/src/lib.rs
index eb4d347e6a9083352397ac1b5c3a800baed8a8d9..8e5885ca9bf2d7b67b017d8575a4059e9ecc5ce2 100644 (file)
--- a/lightning-net-tokio/src/lib.rs
+++ b/lightning-net-tokio/src/lib.rs
@@ -535,7 +535,6 @@ mod tests {
                fn handle_htlc_fail_channel_update(&self, _update: &HTLCFailChannelUpdate) { }
                fn get_next_channel_announcements(&self, _starting_point: u64, _batch_amount: u8) -> Vec<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)> { Vec::new() }
                fn get_next_node_announcements(&self, _starting_point: Option<&PublicKey>, _batch_amount: u8) -> Vec<NodeAnnouncement> { Vec::new() }
-               fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool { false }
                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(()) }

diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index 55d3acdfffec76666122084d57fc1f64168c754a..b392a22ed1996f430cf93472458dfe6f378a3689 100644 (file)
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -831,8 +831,6 @@ pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvide
        /// 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 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.

diff --git a/lightning/src/routing/network_graph.rs b/lightning/src/routing/network_graph.rs
index a16e67529e48243848535e63e27d095c640ba5ef..8075462c938b797d0f8d923d786be9239533317c 100644 (file)
--- a/lightning/src/routing/network_graph.rs
+++ b/lightning/src/routing/network_graph.rs
@@ -105,6 +105,18 @@ impl<C: Deref, L: Deref> NetGraphMsgHandler<C, L> where C::Target: chain::Access
        pub fn read_locked_graph<'a>(&'a self) -> LockedNetworkGraph<'a> {
                LockedNetworkGraph(self.network_graph.read().unwrap())
        }
+
+       /// Returns true when a full routing table sync should be performed with a peer.
+       fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool {
+               //TODO: Determine whether to request a full sync based on the network map.
+               const FULL_SYNCS_TO_REQUEST: usize = 5;
+               if self.full_syncs_requested.load(Ordering::Acquire) < FULL_SYNCS_TO_REQUEST {
+                       self.full_syncs_requested.fetch_add(1, Ordering::AcqRel);
+                       true
+               } else {
+                       false
+               }
+       }
 }
 
 impl<'a> LockedNetworkGraph<'a> {
@@ -207,17 +219,6 @@ impl<C: Deref + Sync + Send, L: Deref + Sync + Send> RoutingMessageHandler for N
                result
        }
 
-       fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool {
-               //TODO: Determine whether to request a full sync based on the network map.
-               const FULL_SYNCS_TO_REQUEST: usize = 5;
-               if self.full_syncs_requested.load(Ordering::Acquire) < FULL_SYNCS_TO_REQUEST {
-                       self.full_syncs_requested.fetch_add(1, Ordering::AcqRel);
-                       true
-               } else {
-                       false
-               }
-       }
-
        /// 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.

diff --git a/lightning/src/util/test_utils.rs b/lightning/src/util/test_utils.rs
index d1daf6bcddd67ffb78ef4a0d6959719de979ad75..c944e572cd4569deb44ee8d06180f64d2440ef41 100644 (file)
--- a/lightning/src/util/test_utils.rs
+++ b/lightning/src/util/test_utils.rs
@@ -316,10 +316,6 @@ impl msgs::RoutingMessageHandler for TestRoutingMessageHandler {
                Vec::new()
        }
 
-       fn should_request_full_sync(&self, _node_id: &PublicKey) -> bool {
-               self.request_full_sync.load(Ordering::Acquire)
-       }
-
        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> {