From: Matt Corallo Date: Thu, 17 Mar 2022 22:04:48 +0000 (+0000) Subject: Rename `RoutingMessageHandler::sync_routing_table` `peer_connected` X-Git-Tag: v0.0.106~18^2~1 X-Git-Url: http://git.bitcoin.ninja/?a=commitdiff_plain;h=b1fb7fdb9bacfa486320f2fbdc594d96b355c85a;p=rust-lightning 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 2582cc597..c5c18b5df 100644 --- 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 { Ok(false) } 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 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 fab396e3c..769d648fc 100644 --- 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 d3ac2ebe9..9d79c6385 100644 --- 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, Option)> { Vec::new() } fn get_next_node_announcements(&self, _starting_point: Option<&PublicKey>, _batch_amount: u8) -> Vec { 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 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 a5e497bb1..8f3511d6d 100644 --- 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 27c2d9de8..3c36cdf06 100644 --- 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(())