Interpret sync_complete in reply_channel_range
authorbmancini55 <bmancini@gmail.com>
Wed, 3 Feb 2021 16:34:48 +0000 (11:34 -0500)
committerbmancini55 <bmancini@gmail.com>
Thu, 4 Feb 2021 14:19:02 +0000 (09:19 -0500)
LN Spec PR #826 changes full_information to indicate completion of a
sequence of reply_channel_range messages.

lightning/src/ln/msgs.rs
lightning/src/routing/network_graph.rs

index 8517e85d8c299436ad42d6bf2b8f27e399a55faa..289cdae4ed760eaeb7206e7d645c7a90bd55f07f 100644 (file)
@@ -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<u64>,
 }
@@ -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);
index 4b53a21ba6bb71d6af51ebc6b892fa54c66075dc..bba99244b4a98624a1725c2d57a7eb2be15b6712 100644 (file)
@@ -264,18 +264,7 @@ impl<C: Deref + Sync + Send, L: Deref + Sync + Send> 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]