-
Notifications
You must be signed in to change notification settings - Fork 129
Add probing service #815
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
base: main
Are you sure you want to change the base?
Add probing service #815
Changes from all commits
963aa9d
3571c5e
c31f1ce
200de80
83ae595
ebb6227
1e73e6e
c470da6
a727bcf
b90f76d
9acf20e
67ea013
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 |
|---|---|---|
|
|
@@ -101,10 +101,12 @@ pub mod logger; | |
| mod message_handler; | ||
| pub mod payment; | ||
| mod peer_store; | ||
| pub mod probing; | ||
| mod runtime; | ||
| mod scoring; | ||
| mod tx_broadcaster; | ||
| mod types; | ||
| mod util; | ||
| mod wallet; | ||
|
|
||
| use std::default::Default; | ||
|
|
@@ -114,6 +116,8 @@ use std::time::{Duration, Instant, SystemTime, UNIX_EPOCH}; | |
| #[cfg(cycle_tests)] | ||
| use std::{any::Any, sync::Weak}; | ||
|
|
||
| #[cfg(feature = "uniffi")] | ||
| use crate::probing::ProbingConfig; | ||
| pub use balance::{BalanceDetails, LightningBalance, PendingSweepBalance}; | ||
| pub use bip39; | ||
| pub use bitcoin; | ||
|
|
@@ -170,6 +174,7 @@ use payment::{ | |
| UnifiedPayment, | ||
| }; | ||
| use peer_store::{PeerInfo, PeerStore}; | ||
| use probing::{run_prober, Prober}; | ||
| use runtime::Runtime; | ||
| pub use tokio; | ||
| use types::{ | ||
|
|
@@ -239,6 +244,7 @@ pub struct Node { | |
| om_mailbox: Option<Arc<OnionMessageMailbox>>, | ||
| async_payments_role: Option<AsyncPaymentsRole>, | ||
| hrn_resolver: Arc<HRNResolver>, | ||
| prober: Option<Arc<Prober>>, | ||
| #[cfg(cycle_tests)] | ||
| _leak_checker: LeakChecker, | ||
| } | ||
|
|
@@ -590,11 +596,19 @@ impl Node { | |
| static_invoice_store, | ||
| Arc::clone(&self.onion_messenger), | ||
| self.om_mailbox.clone(), | ||
| self.prober.clone(), | ||
| Arc::clone(&self.runtime), | ||
| Arc::clone(&self.logger), | ||
| Arc::clone(&self.config), | ||
| )); | ||
|
|
||
| if let Some(prober) = self.prober.clone() { | ||
| let stop_rx = self.stop_sender.subscribe(); | ||
| self.runtime.spawn_cancellable_background_task(async move { | ||
| run_prober(prober, stop_rx).await; | ||
| }); | ||
| } | ||
|
|
||
| // Setup background processing | ||
| let background_persister = Arc::clone(&self.kv_store); | ||
| let background_event_handler = Arc::clone(&event_handler); | ||
|
|
@@ -1067,6 +1081,42 @@ impl Node { | |
| )) | ||
| } | ||
|
|
||
| /// Returns a reference to the [`Prober`], or `None` if no probing strategy is configured. | ||
| pub fn prober(&self) -> Option<&Prober> { | ||
| self.prober.as_deref() | ||
| } | ||
|
|
||
| /// Returns the scorer's estimated `(min, max)` liquidity range for the given channel in the | ||
| /// direction toward `target`, or `None` if the scorer has no data for that channel. | ||
| /// | ||
| /// **Warning:** This is expensive — O(scorer size) per call. It works by serializing the | ||
| /// entire `CombinedScorer` and deserializing it as a plain `ProbabilisticScorer` to access | ||
| /// `estimated_channel_liquidity_range`. Intended for testing and debugging, not hot paths. | ||
| pub fn scorer_channel_liquidity(&self, scid: u64, target: PublicKey) -> Option<(u64, u64)> { | ||
|
Collaborator
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. I don't think we'll want to expose this here. If we think we need this we'd need to work out an API that is more reasonable than returning plain |
||
| use lightning::routing::scoring::{ | ||
| ProbabilisticScorer, ProbabilisticScoringDecayParameters, | ||
| }; | ||
| use lightning::util::ser::{ReadableArgs, Writeable}; | ||
|
|
||
| let target_node_id = lightning::routing::gossip::NodeId::from_pubkey(&target); | ||
|
|
||
| let bytes = { | ||
| let scorer = self.scorer.lock().unwrap(); | ||
| let mut buf = Vec::new(); | ||
| scorer.write(&mut buf).ok()?; | ||
| buf | ||
| }; | ||
|
|
||
| let decay_params = ProbabilisticScoringDecayParameters::default(); | ||
| let prob_scorer = ProbabilisticScorer::read( | ||
| &mut &bytes[..], | ||
| (decay_params, Arc::clone(&self.network_graph), Arc::clone(&self.logger)), | ||
| ) | ||
| .ok()?; | ||
|
|
||
| prob_scorer.estimated_channel_liquidity_range(scid, &target_node_id) | ||
| } | ||
|
|
||
| /// Retrieve a list of known channels. | ||
| pub fn list_channels(&self) -> Vec<ChannelDetails> { | ||
| self.channel_manager.list_channels().into_iter().map(|c| c.into()).collect() | ||
|
|
||
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.
I do wonder if we should allow the user to set the entire
ProbabilisticScoringFeeParametersandProbabilisticScoringDecayParametersvia theProbingConfigBuildermentioned above? Do you see any reason where that would conflict with other API design decisions?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.
I think we should expose these settings (in NodeBuilder, not probing builder).
However these are for fine tuning and should be used only by advanced users. Also I would expose
UserConfig, as for example user cannot decide what features do advertise.I can add builder methods for scoring parameters, though maybe it should be in another PR aimed on exposing settings for an advanced user?
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.
Yes, this is very intentional, as we want to provide a sane/safe API. For example letting user freely choose to set certain parameters if we don't implement them properly will just lead to a lot of footguns, in some circumstances even with the potential for money loss.
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.
In that case I think we don't need to expose ProbabilisticScoringFeeParameters and ProbabilisticScoringFeeParameters by the very reason you mentioned.