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
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

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 {}

@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.

@joostjager joostjager requested a review from tnull September 26, 2025 12:55
@joostjager joostjager force-pushed the multi-listen-fix branch 2 times, most recently from 1bbf1bb to 54bed69 Compare September 26, 2025 13:04
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@joostjager
Copy link
Contributor Author

Now that we established that in any case we need to pick random ports from the lower half, I've also added that commit here.

So that we'll cleanly signal and wait for termination.
@joostjager
Copy link
Contributor Author

Rebased

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.

Feel free to squash!

Previously ldk-node would start binding after the first successful
bind to an address.
To avoid conflicts ("port in use") with ports that were used for
outgoing connections and are now in the TIME_WAIT state.
@joostjager
Copy link
Contributor Author

Squashed

@joostjager joostjager requested a review from tnull October 1, 2025 07:39
@tnull tnull merged commit ca1e5a7 into lightningdevkit:develop Oct 1, 2025
7 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants