+/// If we've sent a ping, and are still awaiting a response, we (or our peer) may need to churn our
+/// (or their) way through the socket receive buffer before receiving the ping.
+///
+/// On a fairly old Arm64 board, with Linux defaults, this can take as long as 20 seconds, not
+/// including any network delays or outbound traffic.
+///
+/// Thus, to avoid needlessly disconnecting a peer, we allow a peer to take this many timer ticks
+/// to respond to a ping, as long as they send us at least one message during each tick or if we
+/// sent a lot of messages, ensuring we aren't actually just disconnected. With a timer tick
+/// interval of five seconds, this translates to about 30 seconds.
+pub const MAX_BUFFER_DRAIN_TICK_INTERVALS: i8 = 6;
+
+/// 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
+/// ensures we don't just fill up our send buffer and leave the peer with too many messages to
+/// process before the next ping.
+pub const BUFFER_DRAIN_MSGS_PER_TICK: usize = 32;
+