Skip to content

Add Custom Pathfinding #303

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.

Sign up for GitHub

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Add Custom Pathfinding #303

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4a74f9f
simln-lib/feat: Add Pathfinder trait
sangbida May 26, 2025
8c43804
simln-lib/test: Add tests for custom pathfinding
sangbida May 31, 2025
e5b94fa
sim_node/feat: Add a default implementation for DefaultPathFinder
sangbida Jun 9, 2025
04842b1
sim_node/feat: Implement Scoring for DefaultPathfinder
chuksys Sep 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Cargo.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

1 change: 1 addition & 0 deletions sim-cli/Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@ futures = "0.3.30"
console-subscriber = { version = "0.4.0", optional = true}
tokio-util = { version = "0.7.13", features = ["rt"] }
openssl = { version = "0.10", features = ["vendored"] }
lightning = { version = "0.0.123" }

[features]
dev = ["console-subscriber"]
19 changes: 14 additions & 5 deletions sim-cli/src/parsing.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,10 @@ use log::LevelFilter;
use serde::{Deserialize, Serialize};
use simln_lib::clock::SimulationClock;
use simln_lib::sim_node::{
ln_node_from_graph, populate_network_graph, ChannelPolicy, CustomRecords, Interceptor,
SimGraph, SimNode, SimulatedChannel,
ln_node_from_graph, populate_network_graph, ChannelPolicy, CustomRecords, DefaultPathFinder,
Interceptor, SimGraph, SimulatedChannel,
};

use simln_lib::{
cln, cln::ClnNode, eclair, eclair::EclairNode, lnd, lnd::LndNode, serializers,
ActivityDefinition, Amount, Interval, LightningError, LightningNode, NodeId, NodeInfo,
Expand Down Expand Up @@ -262,7 +263,7 @@ pub async fn create_simulation_with_network(
(
Simulation<SimulationClock>,
Vec<ActivityDefinition>,
HashMap<PublicKey, Arc<Mutex<SimNode<SimGraph, SimulationClock>>>>,
HashMap<PublicKey, Arc<Mutex<dyn LightningNode>>>,
),
anyhow::Error,
> {
Expand Down Expand Up @@ -309,19 +310,27 @@ pub async fn create_simulation_with_network(
.map_err(|e| SimulationError::SimulatedNetworkError(format!("{:?}", e)))?,
);

// Create the pathfinder instance
let pathfinder = DefaultPathFinder::new(routing_graph.clone());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not pass the pathfinder to create_simulation_with_network? there should be a way to create a simulation with a custom one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense though since DefaultPathFinder depends on the network graph, we would probably have to pass the graph into create_simulation_with_network too which seems unnecessary to me.

If a user needs to create a simulation with a custom pathfinder, don't you think they can simply instantiate their custom pathfinder here? Moreso, if they have a custom pathfinder, they would probably be comfortable using simln-lib directly, no?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we would probably have to pass the graph into create_simulation_with_network too

yeah... don't see any other way.

If a user needs to create a simulation with a custom pathfinder, don't you think they can simply instantiate their custom pathfinder here? Moreso, if they have a custom pathfinder, they would probably be comfortable using simln-lib directly, no?

here how? If using simln as a lib, this create_simulation_with_network function is the one they would use to create a Simulation. They can setup their own custom pathfinder but would need a way to pass it somehow to simln-lib so that a Simulation can be setup using their custom pathfinder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's my perspective - sim-cli is the application layer which should have the default settings which can be used to run a simulation out-of-the-box and simln-lib is the library which users can depend on and which they can pass custom values to, to run custom simulations that are not possible with the default sim-cli application. From what you are saying, the user would be expected to depend on both sim-cli as well as simln-lib. Shouldn't the user just depend on simln-lib (this is making me think create_simulation and create_simulation_with_network methods belong to simln-lib and not sim-cli)?

Copy link
Collaborator

@elnosh elnosh Oct 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hehe woops, my bad, I just realized that create_simulation and create_simulation_with_network are in sim-cli.

(this is making me think create_simulation and create_simulation_with_network methods belong to simln-lib and not sim-cli)?

I saw those (create_simulation and create_simulation_with_network) as lib utils since having users do everything that is in there seemed like a handful. But you made me realize they are not in simln-lib 😅 so what you said makes sense.


// We want the full set of nodes in our graph to return to the caller so that they can take
// custom actions on the simulated network. For the nodes we'll pass our simulation, cast them
// to a dyn trait and exclude any nodes that shouldn't be included in random activity
// generation.
let nodes = ln_node_from_graph(simulation_graph.clone(), routing_graph, clock.clone()).await?;
let nodes = ln_node_from_graph(
simulation_graph.clone(),
routing_graph,
clock.clone(),
pathfinder,
)
.await?;
let mut nodes_dyn: HashMap<_, Arc<Mutex<dyn LightningNode>>> = nodes
.iter()
.map(|(pk, node)| (*pk, Arc::clone(node) as Arc<Mutex<dyn LightningNode>>))
.collect();
for pk in exclude {
nodes_dyn.remove(pk);
}

let validated_activities =
get_validated_activities(&nodes_dyn, nodes_info, sim_params.activity.clone()).await?;

Expand Down
Loading