splice: Implement start_batch
#8335
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hey! I just added a small change to |
ddustin
force-pushed
the
ddustin/start_batch
branch
2 times, most recently
from
35b5281 to
07fa3ad
Compare
I will add the |
ddustin
force-pushed
the
ddustin/start_batch
branch
8 times, most recently
from
cb70577 to
417a728
Compare
We add `start_batch` to match t-bast’s splicing spec and we add a new internal wire type `WIRE_PROTOCOL_BATCH_ELEMENT` using the type number 32899 following the spec in Bolt #1 for application-specific messages: “Custom (types 32768-65535): experimental and application-specific messages” Changelog-Added: support for `start_batch`
The new spec sends `batch_size` in `start_batch` and removes it from `commitment_signed` so we need to stop processing it in `commitment_signed`. Since the tlv is now reduced to one element and that automagically turns it into a direct use TLV so we have to update the code everywhere it is referenced.
Since `batch_size` has moved into this new message, we can’t ignore it anymore and have to process it
We need a way to indiciate failure of the batching system in connectd.
Since handling commit sig batches is coming for multiple locations now, add more explicity error handling so log messages are more useful.
Implement the sending of `start_batch` and `protocol_batch_element` from `channeld` to `connectd`. Each real peer wire message is prefixed with `protocol_batch_element` so connectd can know the size of the message that were batched together. `connectd` intercepts `protocol_batch_element` messages and eats them (doesn’t forward them to peer) to get individual messages out of the batch. It needs this to be able to encrypt them individiaully. Afterwards it recombines the now encrypted messages into a single message to send over the wire to the peer. `channeld` remains responsible for making `start_batch` the first message of the message bundle.
ddustin
force-pushed
the
ddustin/start_batch
branch
from
417a728 to
f3acf0a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement the sending of
start_batchas per t-bast’s spec. We need to receivestart_batchas the new spec movesbatch_sizeout ofcommitment_signedand instead relays that value instart_batch. For sending we implement an internal batching approach.This approach bundles all the message bytes for
start_batchand correspondingcommitment_signeds into a singlepeer_writecall. Because each message needs to be encrypted individually, we introduce an internal peer wire message type,protocol_batch_element. This type is detected byconnectdand is not meant to be sent to the peer.connectdreads the message to get information on the batch element (currently justelement_sizefor the individual message size andchannel_idfor consistency with all other peer_wire message types) and does not forward it along to the peer.Finally
connectdencrypts each message element individually, batches all the encrypted messages into one large byte array, and sends the whole array in one go on the actual wire to the peer.This rigmarole is to make sure no other messages are sent between
start_batchand all of the batch messages -- without introducing any mutexes or locks toconnectd.Changelog-Added: support for
start_batch