From: bmancini55 Date: Wed, 3 Feb 2021 16:34:48 +0000 (-0500) Subject: Interpret sync_complete in reply_channel_range X-Git-Tag: v0.0.13~35^2 X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=commitdiff_plain;h=77690fada2225222015ea50fb40e7e4080a590f5;p=rust-lightning Interpret sync_complete in reply_channel_range LN Spec PR #826 changes full_information to indicate completion of a sequence of reply_channel_range messages. --- diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs index 8517e85d..289cdae4 100644 --- a/lightning/src/ln/msgs.rs +++ b/lightning/src/ln/msgs.rs @@ -602,9 +602,8 @@ pub struct ReplyChannelRange { pub first_blocknum: u32, /// The number of blocks included in the range of the reply pub number_of_blocks: u32, - /// Indicates if the query recipient maintains up-to-date channel - /// information for the chain_hash - pub full_information: bool, + /// True when this is the final reply for a query + pub sync_complete: bool, /// The short_channel_ids in the channel range pub short_channel_ids: Vec, } @@ -1727,7 +1726,7 @@ impl Readable for ReplyChannelRange { let chain_hash: BlockHash = Readable::read(r)?; let first_blocknum: u32 = Readable::read(r)?; let number_of_blocks: u32 = Readable::read(r)?; - let full_information: bool = Readable::read(r)?; + let sync_complete: bool = Readable::read(r)?; // We expect the encoding_len to always includes the 1-byte // encoding_type and that short_channel_ids are 8-bytes each @@ -1755,7 +1754,7 @@ impl Readable for ReplyChannelRange { chain_hash, first_blocknum, number_of_blocks, - full_information, + sync_complete, short_channel_ids }) } @@ -1768,7 +1767,7 @@ impl Writeable for ReplyChannelRange { self.chain_hash.write(w)?; self.first_blocknum.write(w)?; self.number_of_blocks.write(w)?; - self.full_information.write(w)?; + self.sync_complete.write(w)?; encoding_len.write(w)?; (EncodingType::Uncompressed as u8).write(w)?; @@ -2569,7 +2568,7 @@ mod tests { chain_hash: expected_chain_hash, first_blocknum: 756230, number_of_blocks: 1500, - full_information: true, + sync_complete: true, short_channel_ids: vec![0x000000000000008e, 0x0000000000003c69, 0x000000000045a6c4], }; @@ -2582,7 +2581,7 @@ mod tests { assert_eq!(reply_channel_range.chain_hash, expected_chain_hash); assert_eq!(reply_channel_range.first_blocknum, 756230); assert_eq!(reply_channel_range.number_of_blocks, 1500); - assert_eq!(reply_channel_range.full_information, true); + assert_eq!(reply_channel_range.sync_complete, true); assert_eq!(reply_channel_range.short_channel_ids[0], 0x000000000000008e); assert_eq!(reply_channel_range.short_channel_ids[1], 0x0000000000003c69); assert_eq!(reply_channel_range.short_channel_ids[2], 0x000000000045a6c4); diff --git a/lightning/src/routing/network_graph.rs b/lightning/src/routing/network_graph.rs index 4b53a21b..bba99244 100644 --- a/lightning/src/routing/network_graph.rs +++ b/lightning/src/routing/network_graph.rs @@ -264,18 +264,7 @@ impl RoutingMessageHandler for N /// does not match our chain_hash will be rejected when the announcement is /// processed. fn handle_reply_channel_range(&self, their_node_id: &PublicKey, msg: ReplyChannelRange) -> Result<(), LightningError> { - log_debug!(self.logger, "Handling reply_channel_range peer={}, first_blocknum={}, number_of_blocks={}, full_information={}, scids={}", log_pubkey!(their_node_id), msg.first_blocknum, msg.number_of_blocks, msg.full_information, msg.short_channel_ids.len(),); - - // Validate that the remote node maintains up-to-date channel - // information for chain_hash. Some nodes use the full_information - // flag to indicate multi-part messages so we must check whether - // we received SCIDs as well. - if !msg.full_information && msg.short_channel_ids.len() == 0 { - return Err(LightningError { - err: String::from("Received reply_channel_range with no information available"), - action: ErrorAction::IgnoreError, - }); - } + log_debug!(self.logger, "Handling reply_channel_range peer={}, first_blocknum={}, number_of_blocks={}, sync_complete={}, scids={}", log_pubkey!(their_node_id), msg.first_blocknum, msg.number_of_blocks, msg.sync_complete, msg.short_channel_ids.len(),); log_debug!(self.logger, "Sending query_short_channel_ids peer={}, batch_size={}", log_pubkey!(their_node_id), msg.short_channel_ids.len()); let mut pending_events = self.pending_events.lock().unwrap(); @@ -2015,7 +2004,7 @@ mod tests { { let result = net_graph_msg_handler.handle_reply_channel_range(&node_id_1, ReplyChannelRange { chain_hash, - full_information: true, + sync_complete: true, first_blocknum: 0, number_of_blocks: 2000, short_channel_ids: vec![ @@ -2048,22 +2037,6 @@ mod tests { _ => panic!("expected MessageSendEvent::SendShortIdsQuery"), } } - - // Test receipt of a reply that indicates the remote node does not maintain up-to-date - // information for the chain_hash. Because of discrepancies in implementation we use - // full_information=false and short_channel_ids=[] as the signal. - { - // Handle the reply indicating the peer was unable to fulfill our request. - let result = net_graph_msg_handler.handle_reply_channel_range(&node_id_1, ReplyChannelRange { - chain_hash, - full_information: false, - first_blocknum: 1000, - number_of_blocks: 100, - short_channel_ids: vec![], - }); - assert!(result.is_err()); - assert_eq!(result.err().unwrap().err, "Received reply_channel_range with no information available"); - } } #[test]