Rename `RoutingMessageHandler::sync_routing_table` `peer_connected`

Its somewhat strange to have a trait method which is named after
the intended action, rather than the action that occurred, leaving
it up to the implementor what action they want to take.

diff --git a/lightning-net-tokio/src/lib.rs b/lightning-net-tokio/src/lib.rs
index 2582cc597f20d361906271811e8d523f5977516e..c5c18b5df52fb49c075f679d43171c43802d3266 100644 (file)
--- a/lightning-net-tokio/src/lib.rs
+++ b/lightning-net-tokio/src/lib.rs
@@ -496,7 +496,7 @@ mod tests {
                fn handle_channel_update(&self, _msg: &ChannelUpdate) -> Result<bool, LightningError> { Ok(false) }
                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 sync_routing_table(&self, _their_node_id: &PublicKey, _init_msg: &Init) { }
+               fn peer_connected(&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 fab396e3c7112af934021041abfcf2e1f4d609af..769d648fcb697170acb90344b13b19c33fd49de9 100644 (file)
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -886,7 +886,7 @@ pub trait RoutingMessageHandler : MessageSendEventsProvider {
        /// Called when a connection is established with a peer. This can be used to
        /// perform routing table synchronization using a strategy defined by the
        /// implementor.
-       fn sync_routing_table(&self, their_node_id: &PublicKey, init: &Init);
+       fn peer_connected(&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/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs
index d3ac2ebe9a39bf2e918f58dbf4d012ac0434ae99..9d79c6385f45173a794e3ea46fb8c5c054db6d3f 100644 (file)
--- a/lightning/src/ln/peer_handler.rs
+++ b/lightning/src/ln/peer_handler.rs
@@ -69,7 +69,7 @@ impl RoutingMessageHandler for IgnoringMessageHandler {
        fn get_next_channel_announcements(&self, _starting_point: u64, _batch_amount: u8) ->
                Vec<(msgs::ChannelAnnouncement, Option<msgs::ChannelUpdate>, Option<msgs::ChannelUpdate>)> { Vec::new() }
        fn get_next_node_announcements(&self, _starting_point: Option<&PublicKey>, _batch_amount: u8) -> Vec<msgs::NodeAnnouncement> { Vec::new() }
-       fn sync_routing_table(&self, _their_node_id: &PublicKey, _init: &msgs::Init) {}
+       fn peer_connected(&self, _their_node_id: &PublicKey, _init: &msgs::Init) {}
        fn handle_reply_channel_range(&self, _their_node_id: &PublicKey, _msg: msgs::ReplyChannelRange) -> Result<(), LightningError> { Ok(()) }
        fn handle_reply_short_channel_ids_end(&self, _their_node_id: &PublicKey, _msg: msgs::ReplyShortChannelIdsEnd) -> Result<(), LightningError> { Ok(()) }
        fn handle_query_channel_range(&self, _their_node_id: &PublicKey, _msg: msgs::QueryChannelRange) -> Result<(), LightningError> { Ok(()) }
@@ -1018,7 +1018,7 @@ impl<Descriptor: SocketDescriptor, CM: Deref, RM: Deref, L: Deref, CMH: Deref> P
                                        return Err(PeerHandleError{ no_connection_possible: true }.into());
                                }
 
-                               self.message_handler.route_handler.sync_routing_table(&peer.their_node_id.unwrap(), &msg);
+                               self.message_handler.route_handler.peer_connected(&peer.their_node_id.unwrap(), &msg);
 
                                self.message_handler.chan_handler.peer_connected(&peer.their_node_id.unwrap(), &msg);
                                peer.their_features = Some(msg.features);

diff --git a/lightning/src/routing/network_graph.rs b/lightning/src/routing/network_graph.rs
index a5e497bb1cf0f279137fd3f5e923e8972317181d..8f3511d6dd6691f2755de5370964aea3e15ffe8b 100644 (file)
--- a/lightning/src/routing/network_graph.rs
+++ b/lightning/src/routing/network_graph.rs
@@ -395,8 +395,7 @@ where C::Target: chain::Access, L::Target: Logger
        /// 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 sync_routing_table(&self, their_node_id: &PublicKey, init_msg: &Init) {
-
+       fn peer_connected(&self, their_node_id: &PublicKey, init_msg: &Init) {
                // We will only perform a sync with peers that support gossip_queries.
                if !init_msg.features.supports_gossip_queries() {
                        return ();
@@ -2271,7 +2270,7 @@ mod tests {
                // 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);
+                       net_graph_msg_handler.peer_connected(&node_id_1, &init_msg);
                        let events = net_graph_msg_handler.get_and_clear_pending_msg_events();
                        assert_eq!(events.len(), 0);
                }
@@ -2279,7 +2278,7 @@ mod tests {
                // It should send a query_channel_message with the correct information
                {
                        let init_msg = Init { features: InitFeatures::known() };
-                       net_graph_msg_handler.sync_routing_table(&node_id_1, &init_msg);
+                       net_graph_msg_handler.peer_connected(&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] {
@@ -2303,7 +2302,7 @@ mod tests {
                        for n in 1..7 {
                                let node_privkey = &SecretKey::from_slice(&[n; 32]).unwrap();
                                let node_id = PublicKey::from_secret_key(&secp_ctx, node_privkey);
-                               net_graph_msg_handler.sync_routing_table(&node_id, &init_msg);
+                               net_graph_msg_handler.peer_connected(&node_id, &init_msg);
                                let events = net_graph_msg_handler.get_and_clear_pending_msg_events();
                                if n <= 5 {
                                        assert_eq!(events.len(), 1);

diff --git a/lightning/src/util/test_utils.rs b/lightning/src/util/test_utils.rs
index 27c2d9de874ed45abca03dabe171ca238d7288ff..3c36cdf066a5048bbb1b6fe112c2906ac824e6cc 100644 (file)
--- a/lightning/src/util/test_utils.rs
+++ b/lightning/src/util/test_utils.rs
@@ -384,7 +384,7 @@ impl msgs::RoutingMessageHandler for TestRoutingMessageHandler {
                Vec::new()
        }
 
-       fn sync_routing_table(&self, _their_node_id: &PublicKey, _init_msg: &msgs::Init) {}
+       fn peer_connected(&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(())