-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gossip queries: sync complete is back #826
Conversation
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
LGTM. Should we consider adding an error TLV to cover the intent of |
LGTM! In retrospect not having an explicit |
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
Ack: this won't break anything worse than it is now. We might get upset and send an error if the final block is split, so I'll fix that now. |
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
Merging as agreed during the spec meeting (#840) |
- 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`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is true
/false
in a byte
typed value? 0x01
and 0x00
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth opening a PR to fix it, but, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, 0x01. Feel free to clarify if you feel it's needed.
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
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 afull_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. AFAIK, no-one actually reads the
full_information
field and use its info: so it's ok to re-purpose it.Implementations should probably deploy this in multiple phases:
sync_complete
field: set it totrue
only in your lastreply_channel_range
sync_complete
reply_channel_range
A safer approach would be to avoid re-using the
full_information
field and instead introduce a new TLV field.Let me know if you think that's better.
Fixes #804