Skip to content

Conversation

@rustyrussell
Copy link
Contributor

Combined with gossipd connecting to random peers, this gives us an indication of peer latency. This might be useful to someone.

@rustyrussell
Copy link
Contributor Author

Note: failed-connect should note if it's unreachable because there are no addresses using a protocol we support!

@rustyrussell rustyrussell force-pushed the guilt/networkevents branch 4 times, most recently from 3039eb8 to fe4ada6 Compare October 23, 2025 07:06
Copy link
Collaborator

@endothermicdev endothermicdev left a comment

Choose a reason for hiding this comment

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

I think there's a problem with one of the sql insert statements. But otherwise this looks great. I think it will be really useful to automatically log all recent connections.

Do you think it would be worth timing out the ping and logging a lack of pong response, or would that be more problematic than it's worth? I'll try to test this out tomorrow.

* in progress right now) */
if (connect->conn)
io_set_finish(connect->conn, NULL, NULL);
connect_reason = tal_steal(tmpctx, connect->reason);
Copy link
Collaborator

Choose a reason for hiding this comment

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

So an inbound connection when we were also wanting to connect to the peer will still be attributed with our connection request reason?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed. If incoming, we should say "incoming connection while we were trying to connect" instead.

connect_time_nsec = time_to_nsec(timemono_since(connect->start));
tal_free(connect);
} else {
connect_reason = "";
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it be helpful to explicitly label an "unrequested inbound connection" here?

… *try* to connect to.

This is important: if it's tor-only and we don't have a proxy, we will fail
to connect, but it's no indication that the node is unreachable.  Same with
IPv6.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: JSON-RPC: `wait` now has `networkevents` subsystem.
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: JSON-RPC: `sql` now supports the `networkevents` table.
Changelog-Added: JSON-RPC: `delnetworkevent` to delete from listnetworkevents.
Signed-off-by: Rusty Russell <[email protected]>
We also document this in the listnetworkevents command itself.

The test_autoclean_once was getting repetitive, so I cleaned that
up too.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: `autoclean` will remove networkevents after 30 days by default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants