Vec Broadcaster #3448
Vec Broadcaster #3448
Conversation
| /// is ready. | ||
| pub struct VecBroadcaster { | ||
| channel_id: ChannelId, | ||
| transactions: Mutex<Vec<Transaction>>, |
There was a problem hiding this comment.
As we'll still want to broadcast the individual packages, this might need to be a Vec<Vec<Transaction>>
There was a problem hiding this comment.
Sorry, trying to understand nomenclature, Package == Vec? If so, why do we need this? I.e. release_transactions broadcasts the whole vec of transactions, why some subsets of it need to be broadcasted separately?
| } | ||
|
|
||
| /// Used to actually broadcast stored transactions to the network. | ||
| #[instrument(skip_all, fields(channel = %self.channel_id))] |
There was a problem hiding this comment.
I'm not sure we require the instrument statment here?
There was a problem hiding this comment.
oh my bad, removed it and replaced tracing logging with ldk logger
|
|
||
| impl BroadcasterInterface for VecBroadcaster { | ||
| fn broadcast_transactions(&self, txs: &[&Transaction]) { | ||
| let mut tx_storage = self.transactions.lock(); |
There was a problem hiding this comment.
| let mut tx_storage = self.transactions.lock(); | |
| let mut tx_storage = self.transactions.lock().unwrap(); |
| fn broadcast_transactions(&self, txs: &[&Transaction]) { | ||
| let mut tx_storage = self.transactions.lock(); | ||
| for tx in txs { | ||
| tx_storage.push((*tx).to_owned()) |
There was a problem hiding this comment.
I think we might want to see if we can dedup the packages before pushing, i.e., possibly only keep the latest version of a transaction, for example if we'd bump over and over again.
There was a problem hiding this comment.
I envision this broadcaster to be used in channel monitor deserializer and I don't think it will create multiple versions of the same transaction. Do you see any other use cases?
yellowred
force-pushed
the
oleg_vec_broadcaster
branch
from
62671a2 to
8f3f61e
Compare
Implementation of `BroacasterInterface` that does not broadcast transactions immediately, but stores them internally to broadcast later with a call to `release_transactions`.
yellowred
force-pushed
the
oleg_vec_broadcaster
branch
from
8f3f61e to
22554ee
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3448 +/- ##
==========================================
- Coverage 88.41% 88.39% -0.02%
==========================================
Files 149 149
Lines 112959 112975 +16
Branches 112959 112975 +16
==========================================
- Hits 99871 99863 -8
- Misses 10616 10634 +18
- Partials 2472 2478 +6 ☔ View full report in Codecov by Sentry. |
|
I'm not sure if there's a need for this to be upstreamed, it seems like a somewhat niche use case? |
The idea is to have better separation between deserializer and claim broadcaster. Originally I was thinking to have a separate function that deserializes a monitor and claims separately, which allows the user to choose what to do with this data, but eventually we decided to not change anything existing and just solve this by injecting vec broadcaster #3396 (comment) |
|
I think I agree - I don't think we need to expose this publicly, but I think it may be a useful internal utility to build #3428. Doing it as an internal utility in #3428 also means that we can make the implementation more robust - we can automatically broadcast for the user once we're up and running (e.g. during block connection) so that a bug on the user's end failing to fetch the to-broadcast set won't cause them to accidentally not broadcast at all. |
Implementation of
BroacasterInterfacethat does not broadcast transactions immediately, but stores them internally to broadcast later with a call torelease_transactions.