Skip to content

Conversation

joostjager
Copy link
Contributor

Previously ldk-node would start binding after the first successful bind to an address.

Also fixes #318

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 22, 2025

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

listening_logger,
"Stopping listening to inbound connections."
let logger = Arc::clone(&listening_logger);
let listeners = self.runtime.block_on(async move {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need to block if we want to return an error.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, I see the point. I guess we need to if we want to abort on error for now, but we'll probably make start async soonish anyways.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alternative is to use non-tokio binds here.

@joostjager joostjager requested a review from tnull September 22, 2025 12:41
peer_store: Arc<PeerStore<Arc<Logger>>>,
payment_store: Arc<PaymentStore>,
is_running: Arc<RwLock<bool>>,
is_listening: Arc<AtomicBool>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Huh, please don't drop the is_listening field, we also support nodes that don't allow any inbound connections and want to indicate whether we're listening or not to a port or not here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Discussed offline. This would just be a reflection of the config set.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Kept it in, but dropped the polling for it which is no longer necessary.

listening_logger,
"Stopping listening to inbound connections."
let logger = Arc::clone(&listening_logger);
let listeners = self.runtime.block_on(async move {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, I see the point. I guess we need to if we want to abort on error for now, but we'll probably make start async soonish anyways.

src/lib.rs Outdated
res = listener.accept() => {
let tcp_stream = res.unwrap().0;
let peer_mgr = Arc::clone(&peer_mgr);
tokio::spawn(async move {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Mhh, looks pre-existing, but we should probably also use spawn_cancellable_background_task for this.

src/lib.rs Outdated
for addr in &*bind_addrs {
match tokio::net::TcpListener::bind(addr).await {
Ok(listener) => {
log_trace!(logger, "Bound to {}", addr);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we make this message a bit more verbose?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Quite vague indeed. Made it Listener bound to {}

So that we'll cleanly signal and wait for termination.
Previously ldk-node would start binding after the first successful
bind to an address.
@joostjager joostjager force-pushed the multi-listen-fix branch 2 times, most recently from 167555c to b1cc7f3 Compare September 23, 2025 08:00
@joostjager
Copy link
Contributor Author

With both ports being bound, the chances of a failure increase. I've added a netstat call to see where the port is being used, and it seems there are a lot of ports in TIME_WAIT status. Perhaps because of polling that happened previously?

A good fix might be to pick ports from a range that doesn't include the ephemeral ports.

@joostjager
Copy link
Contributor Author

Removed the port range change from this PR again, needs further investigation.

@joostjager joostjager self-assigned this Sep 25, 2025
Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Changes here look good, maybe could use a test to check we're listening on all ports as expected? Although maybe it's trivial/redundant?

More generally, where are we at with this? Do you still intend to investigate the port collisions etc. and include fixes as part of this PR, or do you intend to split that out?

@joostjager
Copy link
Contributor Author

Test added.

More generally, where are we at with this? Do you still intend to investigate the port collisions etc. and include fixes as part of this PR, or do you intend to split that out?

Split it out, I think we can get this out of the way first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants