From 252280d6bfda49a7ed4fd5d427eed5c74af65ae5 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Mon, 7 Mar 2022 19:02:15 +0000 Subject: [PATCH] Reduce the number of timer ticks a peer is allowed to take In 2d3a2108979adca6b7632e2d59c10e4b131e8bf4, we increased the default ping timer in `lightning-background-processor` to ten seconds from five. However, we didn't change the timer count at which we disconnect peers if they're not responding, which we likely should have done. We do so here, as well as update the documentation for `PeerManager::timer_tick_occurred` to suggest always ticking the timer every ten seconds instead of five. --- lightning/src/ln/peer_handler.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lightning/src/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs index b910d4bf..d3ac2ebe 100644 --- a/lightning/src/ln/peer_handler.rs +++ b/lightning/src/ln/peer_handler.rs @@ -307,12 +307,12 @@ const OUTBOUND_BUFFER_LIMIT_DROP_GOSSIP: usize = OUTBOUND_BUFFER_LIMIT_READ_PAUS /// Thus, to avoid needlessly disconnecting a peer, we allow a peer to take this many timer ticks /// per connected peer to respond to a ping, as long as they send us at least one message during /// each tick, ensuring we aren't actually just disconnected. -/// With a timer tick interval of five seconds, this translates to about 30 seconds per connected +/// With a timer tick interval of ten seconds, this translates to about 40 seconds per connected /// peer. /// /// When we improve parallelism somewhat we should reduce this to e.g. this many timer ticks per /// two connected peers, assuming most LDK-running systems have at least two cores. -const MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER: i8 = 6; +const MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER: i8 = 4; /// This is the minimum number of messages we expect a peer to be able to handle within one timer /// tick. Once we have sent this many messages since the last ping, we send a ping right away to @@ -1572,9 +1572,9 @@ impl P /// Send pings to each peer and disconnect those which did not respond to the last round of /// pings. /// - /// This may be called on any timescale you want, however, roughly once every five to ten - /// seconds is preferred. The call rate determines both how often we send a ping to our peers - /// and how much time they have to respond before we disconnect them. + /// This may be called on any timescale you want, however, roughly once every ten seconds is + /// preferred. The call rate determines both how often we send a ping to our peers and how much + /// time they have to respond before we disconnect them. /// /// May call [`send_data`] on all [`SocketDescriptor`]s. Thus, be very careful with reentrancy /// issues! -- 2.30.2