From edd45ecf22095ce97c1b5e9136a7d79351bd68cb Mon Sep 17 00:00:00 2001 From: Bastien Teinturier <31281497+t-bast@users.noreply.github.com> Date: Mon, 15 Feb 2021 21:37:06 +0100 Subject: [PATCH] Gossip queries: sync complete is back (#826) We previously insisted that `reply_channel_range` messages were not overlapping: blocks content could not be split across multiple messages. This made it possible to implicitly figure out when sync was complete, so we re-purposed the previous `complete` field to a `full_information` field. We now revert that change to allow blocks to be split across multiple messages. An explicit flag is thus needed to signal that sync is complete. Fixes #804 --- 07-routing-gossip.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index a27c2cd60..b89c3d222 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -723,7 +723,7 @@ Though it is possible, it would not be very useful to ask for checksums without * [`chain_hash`:`chain_hash`] * [`u32`:`first_blocknum`] * [`u32`:`number_of_blocks`] - * [`byte`:`full_information`] + * [`byte`:`sync_complete`] * [`u16`:`len`] * [`len*byte`:`encoded_short_ids`] * [`reply_channel_range_tlvs`:`tlvs`] @@ -762,7 +762,7 @@ Where: The checksum of a `channel_update` is the CRC32C checksum as specified in [RFC3720](https://tools.ietf.org/html/rfc3720#appendix-B.4) of this `channel_update` without its `signature` and `timestamp` fields. -This allows to query for channels within specific blocks. +This allows querying for channels within specific blocks. #### Requirements @@ -781,23 +781,21 @@ The receiver of `query_channel_range`: - MUST set with `chain_hash` equal to that of `query_channel_range`, - MUST limit `number_of_blocks` to the maximum number of blocks whose results could fit in `encoded_short_ids` - - if does not maintain up-to-date channel information for `chain_hash`: - - MUST set `full_information` to 0. - - otherwise: - - SHOULD set `full_information` to 1. + - MAY split block contents across multiple `reply_channel_range`. - the first `reply_channel_range` message: - MUST set `first_blocknum` less than or equal to the `first_blocknum` in `query_channel_range` - MUST set `first_blocknum` plus `number_of_blocks` greater than `first_blocknum` in `query_channel_range`. - successive `reply_channel_range` message: - - MUST set `first_blocknum` to the previous `first_blocknum` plus `number_of_blocks`. + - MUST have `first_blocknum` equal or greater than the previous `first_blocknum`. + - MUST set `sync_complete` to `false` if this is not the final `reply_channel_range`. - the final `reply_channel_range` message: - MUST have `first_blocknum` plus `number_of_blocks` equal or greater than the `query_channel_range` `first_blocknum` plus `number_of_blocks`. + - MUST set `sync_complete` to `true`. If the incoming message includes `query_option`, the receiver MAY append additional information to its reply: - if bit 0 in `query_option_flags` is set, the receiver MAY append a `timestamps_tlv` that contains `channel_update` timestamps for all `short_chanel_id`s in `encoded_short_ids` - if bit 1 in `query_option_flags` is set, the receiver MAY append a `checksums_tlv` that contains `channel_update` checksums for all `short_chanel_id`s in `encoded_short_ids` - #### Rationale A single response might be too large for a single packet, so multiple replies