Struct LiquidityManager 

pub struct LiquidityManager<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
    ES::Target: EntropySource,
    CM::Target: AChannelManager,
    C::Target: Filter,
{ /* private fields */ }

The main interface into LSP functionality.

Should be used as a CustomMessageHandler for your PeerManager’s MessageHandler.

Users should provide a callback to process queued messages via LiquidityManager::set_process_msgs_callback post construction. This allows the LiquidityManager to wake the PeerManager when there are pending messages to be sent.

Users need to continually poll LiquidityManager::get_and_clear_pending_events in order to surface Event’s that likely need to be handled.

If the LSPS2 service is configured, users must forward the following parameters from LDK events:

• Event::HTLCIntercepted to LSPS2ServiceHandler::htlc_intercepted
• Event::ChannelReady to LSPS2ServiceHandler::channel_ready
• Event::HTLCHandlingFailed to LSPS2ServiceHandler::htlc_handling_failed
• Event::PaymentForwarded to LSPS2ServiceHandler::payment_forwarded

Implementations

impl<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone> LiquidityManager<ES, CM, C>

where ES::Target: EntropySource, CM::Target: AChannelManager, C::Target: Filter,

pub fn new( entropy_source: ES, channel_manager: CM, chain_source: Option<C>, chain_params: Option<ChainParameters>, service_config: Option<LiquidityServiceConfig>, client_config: Option<LiquidityClientConfig>, ) -> Self

Constructor for the LiquidityManager.

Sets up the required protocol message handlers based on the given LiquidityClientConfig and LiquidityServiceConfig.

pub fn lsps0_client_handler(&self) -> &LSPS0ClientHandler<ES>

Returns a reference to the LSPS0 client-side handler.

pub fn lsps0_service_handler(&self) -> Option<&LSPS0ServiceHandler>

Returns a reference to the LSPS0 server-side handler.

pub fn lsps1_client_handler(&self) -> Option<&LSPS1ClientHandler<ES>>

Returns a reference to the LSPS1 client-side handler.

The returned hendler allows to initiate the LSPS1 client-side flow, i.e., allows to request channels from the configured LSP.

pub fn lsps2_client_handler(&self) -> Option<&LSPS2ClientHandler<ES>>

Returns a reference to the LSPS2 client-side handler.

The returned hendler allows to initiate the LSPS2 client-side flow. That is, it allows to retrieve all necessary data to create ‘just-in-time’ invoices that, when paid, will have the configured LSP open a ‘just-in-time’ channel.

pub fn lsps2_service_handler(&self) -> Option<&LSPS2ServiceHandler<CM>>

Returns a reference to the LSPS2 server-side handler.

The returned hendler allows to initiate the LSPS2 service-side flow.

pub fn set_process_msgs_callback<F: 'static + ProcessMessagesCallback>( &self, callback: F, )

Allows to set a callback that will be called after new messages are pushed to the message queue.

Usually, you’ll want to use this to call PeerManager::process_events to clear the message queue. For example:

let process_msgs_pm = Arc::clone(&my_peer_manager);
let process_msgs_callback = move || process_msgs_pm.process_events();

my_liquidity_manager.set_process_msgs_callback(process_msgs_callback);

pub fn wait_next_event(&self) -> Event

Available on crate feature std only.

Blocks the current thread until next event is ready and returns it.

Typically you would spawn a thread or task that calls this in a loop.

Note: Users must handle events as soon as possible to avoid an increased event queue memory footprint. We will start dropping any generated events after MAX_EVENT_QUEUE_SIZE has been reached.

pub fn next_event(&self) -> Option<Event>

Returns Some if an event is ready.

Typically you would spawn a thread or task that calls this in a loop.

Note: Users must handle events as soon as possible to avoid an increased event queue memory footprint. We will start dropping any generated events after MAX_EVENT_QUEUE_SIZE has been reached.

pub async fn next_event_async(&self) -> Event

Asynchronously polls the event queue and returns once the next event is ready.

Typically you would spawn a thread or task that calls this in a loop.

Note: Users must handle events as soon as possible to avoid an increased event queue memory footprint. We will start dropping any generated events after MAX_EVENT_QUEUE_SIZE has been reached.

pub fn get_and_clear_pending_events(&self) -> Vec<Event>

Returns and clears all events without blocking.

Typically you would spawn a thread or task that calls this in a loop.

Note: Users must handle events as soon as possible to avoid an increased event queue memory footprint. We will start dropping any generated events after MAX_EVENT_QUEUE_SIZE has been reached.

Trait Implementations

impl<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone> Confirm for LiquidityManager<ES, CM, C>

where ES::Target: EntropySource, CM::Target: AChannelManager, C::Target: Filter,

fn transactions_confirmed( &self, _header: &Header, _txdata: &TransactionData<'_>, _height: u32, )

Notifies LDK of transactions confirmed in a block with a given header and height.

fn transaction_unconfirmed(&self, _txid: &Txid)

Notifies LDK of a transaction that is no longer confirmed as result of a chain reorganization.

fn best_block_updated(&self, header: &Header, height: u32)

Notifies LDK of an update to the best header connected at the given height.

fn get_relevant_txids(&self) -> Vec<(Txid, u32, Option<BlockHash>)>

Returns transactions that must be monitored for reorganization out of the chain along with the height and the hash of the block as part of which it had been previously confirmed.

impl<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone> CustomMessageHandler for LiquidityManager<ES, CM, C>

where ES::Target: EntropySource, CM::Target: AChannelManager, C::Target: Filter,

fn handle_custom_message( &self, msg: Self::CustomMessage, sender_node_id: PublicKey, ) -> Result<(), LightningError>

Handles the given message sent from sender_node_id, possibly producing messages for CustomMessageHandler::get_and_clear_pending_msg to return and thus for PeerManager to send.

fn get_and_clear_pending_msg(&self) -> Vec<(PublicKey, Self::CustomMessage)>

Returns the list of pending messages that were generated by the handler, clearing the list in the process. Each message is paired with the node id of the intended recipient. If no connection to the node exists, then the message is simply not sent.

fn provided_node_features(&self) -> NodeFeatures

Gets the node feature flags which this handler itself supports. All available handlers are queried similarly and their feature flags are OR’d together to form the NodeFeatures which are broadcasted in our NodeAnnouncement message.

fn provided_init_features(&self, _their_node_id: PublicKey) -> InitFeatures

Gets the init feature flags which should be sent to the given peer. All available handlers are queried similarly and their feature flags are OR’d together to form the InitFeatures which are sent in our Init message.

fn peer_disconnected(&self, counterparty_node_id: PublicKey)

Indicates a peer disconnected.

fn peer_connected(&self, _: PublicKey, _: &Init, _: bool) -> Result<(), ()>

Handle a peer connecting.

impl<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone> CustomMessageReader for LiquidityManager<ES, CM, C>

where ES::Target: EntropySource, CM::Target: AChannelManager, C::Target: Filter,

type CustomMessage = RawLSPSMessage

The type of the message decoded by the implementation.

fn read<RD: Read>( &self, message_type: u16, buffer: &mut RD, ) -> Result<Option<Self::CustomMessage>, DecodeError>

Decodes a custom message to CustomMessageType. If the given message type is known to the implementation and the message could be decoded, must return Ok(Some(message)). If the message type is unknown to the implementation, must return Ok(None). If a decoding error occur, must return Err(DecodeError::X) where X details the encountered error.

impl<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone> Listen for LiquidityManager<ES, CM, C>

where ES::Target: EntropySource, CM::Target: AChannelManager, C::Target: Filter,

fn filtered_block_connected( &self, header: &Header, txdata: &TransactionData<'_>, height: u32, )

Notifies the listener that a block was added at the given height, with the transaction data possibly filtered.

fn block_disconnected(&self, header: &Header, height: u32)

Notifies the listener that a block was removed at the given height.

fn block_connected(&self, block: &Block, height: u32)

Notifies the listener that a block was added at the given height.