-
Notifications
You must be signed in to change notification settings - Fork 409
Move events into ChannelMonitor from ManyChannelMonitor #520
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
Changes from all commits
bfd4ac4
26008bb
0ebf70d
9ff6f29
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,18 +4,12 @@ | |
//! Because we don't have a built-in runtime, it's up to the client to call events at a time in the | ||
//! future, as well as generate and broadcast funding transactions handle payment preimages and a | ||
//! few other things. | ||
//! | ||
//! Note that many events are handled for you by PeerHandler, so in the common design of having a | ||
//! PeerManager which marshalls messages to ChannelManager and Router you only need to call | ||
//! process_events on the PeerHandler and then get_and_clear_pending_events and handle the events | ||
//! that bubble up to the surface. If, however, you do not have a PeerHandler managing a | ||
//! ChannelManager you need to handle all of the events which may be generated. | ||
//TODO: We need better separation of event types ^ | ||
|
||
use ln::msgs; | ||
use ln::channelmanager::{PaymentPreimage, PaymentHash}; | ||
use chain::transaction::OutPoint; | ||
use chain::keysinterface::SpendableOutputDescriptor; | ||
use util::ser::{Writeable, Writer, MaybeReadable, Readable}; | ||
|
||
use bitcoin::blockdata::script::Script; | ||
|
||
|
@@ -24,6 +18,10 @@ use secp256k1::key::PublicKey; | |
use std::time::Duration; | ||
|
||
/// An Event which you should probably take some action in response to. | ||
/// | ||
/// Note that while Writeable and Readable are implemented for Event, you probably shouldn't use | ||
/// them directly as they don't round-trip exactly (for example FundingGenerationReady is never | ||
/// written as it makes no sense to respond to it after reconnecting to peers). | ||
pub enum Event { | ||
/// Used to indicate that the client should generate a funding transaction with the given | ||
/// parameters and then call ChannelManager::funding_transaction_generated. | ||
|
@@ -108,6 +106,91 @@ pub enum Event { | |
}, | ||
} | ||
|
||
impl Writeable for Event { | ||
fn write<W: Writer>(&self, writer: &mut W) -> Result<(), ::std::io::Error> { | ||
match self { | ||
&Event::FundingGenerationReady { .. } => { | ||
0u8.write(writer)?; | ||
// We never write out FundingGenerationReady events as, upon disconnection, peers | ||
// drop any channels which have not yet exchanged funding_signed. | ||
}, | ||
&Event::FundingBroadcastSafe { ref funding_txo, ref user_channel_id } => { | ||
1u8.write(writer)?; | ||
funding_txo.write(writer)?; | ||
user_channel_id.write(writer)?; | ||
}, | ||
&Event::PaymentReceived { ref payment_hash, ref amt } => { | ||
2u8.write(writer)?; | ||
payment_hash.write(writer)?; | ||
amt.write(writer)?; | ||
}, | ||
&Event::PaymentSent { ref payment_preimage } => { | ||
3u8.write(writer)?; | ||
payment_preimage.write(writer)?; | ||
}, | ||
&Event::PaymentFailed { ref payment_hash, ref rejected_by_dest, | ||
#[cfg(test)] | ||
ref error_code, | ||
} => { | ||
4u8.write(writer)?; | ||
payment_hash.write(writer)?; | ||
rejected_by_dest.write(writer)?; | ||
#[cfg(test)] | ||
error_code.write(writer)?; | ||
}, | ||
&Event::PendingHTLCsForwardable { time_forwardable: _ } => { | ||
5u8.write(writer)?; | ||
// We don't write the time_fordwardable out at all, as we presume when the user | ||
// deserializes us at least that much time has elapsed. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. About the assumption than some time has elapsed, I' m not sure, some people where interested by some HA scheme where you synchronize in real-time state between different ChannelManager. Dunno if it makes sense right now with current locking of ChannelHolder but still something to have in mind.. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, certainly isn't a thing you can do now, but also no big deal - if the user did some kind of crazy serialize-to-disk thing and then ends up relaying pending HTLCs a few seconds early, not really any harm done. |
||
}, | ||
&Event::SpendableOutputs { ref outputs } => { | ||
6u8.write(writer)?; | ||
(outputs.len() as u64).write(writer)?; | ||
for output in outputs.iter() { | ||
output.write(writer)?; | ||
} | ||
}, | ||
} | ||
Ok(()) | ||
} | ||
} | ||
impl<R: ::std::io::Read> MaybeReadable<R> for Event { | ||
fn read(reader: &mut R) -> Result<Option<Self>, msgs::DecodeError> { | ||
match Readable::read(reader)? { | ||
0u8 => Ok(None), | ||
1u8 => Ok(Some(Event::FundingBroadcastSafe { | ||
funding_txo: Readable::read(reader)?, | ||
user_channel_id: Readable::read(reader)?, | ||
})), | ||
2u8 => Ok(Some(Event::PaymentReceived { | ||
payment_hash: Readable::read(reader)?, | ||
amt: Readable::read(reader)?, | ||
})), | ||
3u8 => Ok(Some(Event::PaymentSent { | ||
payment_preimage: Readable::read(reader)?, | ||
})), | ||
4u8 => Ok(Some(Event::PaymentFailed { | ||
payment_hash: Readable::read(reader)?, | ||
rejected_by_dest: Readable::read(reader)?, | ||
#[cfg(test)] | ||
error_code: Readable::read(reader)?, | ||
})), | ||
5u8 => Ok(Some(Event::PendingHTLCsForwardable { | ||
time_forwardable: Duration::from_secs(0) | ||
})), | ||
6u8 => { | ||
let outputs_len: u64 = Readable::read(reader)?; | ||
let mut outputs = Vec::new(); | ||
for _ in 0..outputs_len { | ||
outputs.push(Readable::read(reader)?); | ||
} | ||
Ok(Some(Event::SpendableOutputs { outputs })) | ||
}, | ||
_ => Err(msgs::DecodeError::InvalidValue) | ||
} | ||
} | ||
} | ||
|
||
/// An event generated by ChannelManager which indicates a message should be sent to a peer (or | ||
/// broadcast to most peers). | ||
/// These events are handled by PeerManager::process_events if you are using a PeerManager. | ||
|
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.
Should be documented in ChannelMonitor struct than its Events are invariant between round-trip (contrary to ChannelManager ones and previous commit)?
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.
We should just fix it in ChannelManager and serialize them out, instead of adding a comment. I did add a comment to ChannelMonitor.