Repeat ping request periodically #416

dharjeezy · 2025-07-19T15:06:39Z

closes #415

dmitry-markin · 2025-07-21T09:17:12Z

src/protocol/libp2p/ping/mod.rs

+                _ = interval.tick() => {
+                    for peer in &self.peers {
+                        tracing::trace!(target: LOG_TARGET, ?peer, "sending ping");
+                        if let Err(error) = self.service.open_substream(*peer) {


The libp2p ping protocol spec states that the repeated pings should go on the same substream: https://github.com/libp2p/specs/blob/master/ping/ping.md

Because of this, the issue is actually more difficult due to the need to not keep the connection alive by this ping substream.

I don't think we should break the spec even if it works with the current libp2p implementation. @lexnv what do you think?

Indeed, I would comply with the libp2p spec as much as possible. The main issue would be that we cannot distinguish ping susbtreams for the keep alive connection tracker 🤔

Are we entirely convinced we need to implement this for ping?

we'll need to adjust the substream API to expose that the substream is ping (accounting towards the keepalive)

how do we treat failures here? If we cannot open a substream should we terminate the connection? If so, we need to propagate again to the higher levels the signal to terminate the connection

offhand, from ping we'll need to propagate towards the transport manager, and from the transport manager we'll need to propagate to individual connections

dmitry-markin

Hey, this is going in the right direction, but there should be a way to simplify the implementation by not introducing separate async tasks for inbound/outbound substreams and not adding command channels. It should be possible to implement polling of inbound substreams by putting them into FuturesUnordered or, may be, tokio_stream::StreamMap. The latter should be quite easy as there is maximum one inbound substream allowed from any remote peer as per ping spec: https://github.com/libp2p/specs/blob/master/ping/ping.md

dmitry-markin · 2025-10-21T14:41:56Z

Hey, this is going in the right direction, but there should be a way to simplify the implementation by not introducing separate async tasks for inbound/outbound substreams and not adding command channels. It should be possible to implement polling of inbound substreams by putting them into FuturesUnordered or, may be, tokio_stream::StreamMap. The latter should be quite easy as there is maximum one inbound substream allowed from any remote peer as per ping spec: https://github.com/libp2p/specs/blob/master/ping/ping.md

tokio_stream::StreamMap might not work because we need to also write to substream and not only poll it, but still there should be a way to simplify the code.

dharjeezy · 2025-11-29T11:19:33Z

Hey, this is going in the right direction, but there should be a way to simplify the implementation by not introducing separate async tasks for inbound/outbound substreams and not adding command channels. It should be possible to implement polling of inbound substreams by putting them into FuturesUnordered or, may be, tokio_stream::StreamMap. The latter should be quite easy as there is maximum one inbound substream allowed from any remote peer as per ping spec: https://github.com/libp2p/specs/blob/master/ping/ping.md

tokio_stream::StreamMap might not work because we need to also write to substream and not only poll it, but still there should be a way to simplify the code.

@dmitry-markin can you check my current implementation

dmitry-markin

Hey hey, nice use of SplitStream/SplitSink! I think what is missing is a cleaner separation between inbound and outbound substreams. On inbound substreams we should only respond to incoming pings, and on outbound send pings ourself. It would be better than relying on the presence of the time in the map, which can get screwed when we both send pings to a peer and receive pings from it.

dharjeezy · 2025-12-14T08:41:54Z

Hey hey, nice use of SplitStream/SplitSink! I think what is missing is a cleaner separation between inbound and outbound substreams. On inbound substreams we should only respond to incoming pings, and on outbound send pings ourself. It would be better than relying on the presence of the time in the map, which can get screwed when we both send pings to a peer and receive pings from it.

i have done this now @dmitry-markin

haikoschol · 2025-12-17T09:36:25Z

Out of scope for this PR but I noticed that ping::config::MAX_FAILURES is not used anywhere. Should we create an issue for that?

haikoschol

FWIW, I ran the following tests, using a litep2p listener and webrtc transport:

Dialer	Listener -> Dialer Pings	Dialer -> Listener Pings
libp2p	❌	✅
"minimal smoldot env"	✅	✅

The failing outbound pings with libp2p is an unrelated issue (#494).

haikoschol · 2025-12-17T09:22:42Z

src/protocol/libp2p/ping/mod.rs

-    /// Pending outbound substreams.
-    pending_outbound: FuturesUnordered<BoxFuture<'static, crate::Result<(PeerId, Duration)>>>,
+    /// Streams we read Pings from.
+    /// Keyed by a local counter to handle multiple streams per peer if necessary.


As Dmitry mentioned, there should be only one inbound ping substream per peer. Can we simplify this? I guess just using the PeerId like in outbound_sinks?

haikoschol · 2025-12-17T09:33:00Z

src/protocol/libp2p/ping/mod.rs


 /// Log target for the file.
 const LOG_TARGET: &str = "litep2p::ipfs::ping";
+const PING_TIMEOUT: Duration = Duration::from_secs(10);


Suggested change

const PING_TIMEOUT: Duration = Duration::from_secs(10);

Since it is unused. However, we probably want to have a timeout for receiving pongs. Arguably out of scope for this PR though.

haikoschol · 2025-12-17T09:38:20Z

src/protocol/libp2p/ping/mod.rs

+
+                _ = interval.tick() => {
+                    for (peer, sink) in self.outbound_sinks.iter_mut() {
+                        let payload = vec![0u8; 32];


We should keep this TODO comment:

// TODO: https://github.com/paritytech/litep2p/issues/134 generate random payload and verify it

haikoschol · 2025-12-17T09:40:09Z

src/protocol/libp2p/ping/mod.rs

+                        self.ping_times.insert(*peer, Instant::now());
+                        tracing::trace!(target: LOG_TARGET, ?peer, "sending ping");
+
+                        if let Err(error) = sink.send(Bytes::from(payload)).await {
+                             tracing::debug!(target: LOG_TARGET, ?peer, ?error, "failed to send ping");
+
+                        }


Suggested change

self.ping_times.insert(*peer, Instant::now());

tracing::trace!(target: LOG_TARGET, ?peer, "sending ping");

if let Err(error) = sink.send(Bytes::from(payload)).await {

tracing::debug!(target: LOG_TARGET, ?peer, ?error, "failed to send ping");

}

tracing::trace!(target: LOG_TARGET, ?peer, "sending ping");

if let Err(error) = sink.send(Bytes::from(payload)).await {

tracing::debug!(target: LOG_TARGET, ?peer, ?error, "failed to send ping");

} else {

self.ping_times.insert(*peer, Instant::now());

}

haikoschol · 2025-12-17T09:40:45Z

src/protocol/libp2p/ping/mod.rs

+                    }
+                }
+
+                // Handle Outbound Responses (Ping is expected here)


Suggested change

// Handle Outbound Responses (Ping is expected here)

// Handle Inbound Pings

haikoschol · 2025-12-17T09:43:02Z

src/protocol/libp2p/ping/mod.rs

+                Some((id, event)) = self.inbound_streams.next() => {
+                    match event {
+                        Ok(payload) => {
+                             if let Some(sink) = self.inbound_sinks.get_mut(&id) {


Consider logging when there's no sink for a peer ID.

haikoschol · 2025-12-17T09:43:18Z

src/protocol/libp2p/ping/mod.rs

+                                 }
+                             }
+                        }
+                        Err(_) => {


Consider logging the error.

haikoschol · 2025-12-17T09:48:20Z

src/protocol/libp2p/ping/mod.rs

-                                    ping: elapsed,
-                                })
-                                .await;
+                        Ok(payload) => {


Suggested change

Ok(payload) => {

Ok(_payload) => {

haikoschol · 2025-12-17T10:34:46Z

src/protocol/libp2p/ping/mod.rs

 //! [`/ipfs/ping/1.0.0`](https://github.com/libp2p/specs/blob/master/ping/ping.md) implementation.

 use crate::{
    error::{Error, SubstreamError},


Suggested change

error::{Error, SubstreamError},

Repeat ping request periodically

80e7fdd

dmitry-markin reviewed Jul 21, 2025

View reviewed changes

keep substream open by introducing stateful peer

d6b3909

dharjeezy requested review from dmitry-markin and lexnv October 7, 2025 10:59

dmitry-markin reviewed Oct 21, 2025

View reviewed changes

use stream map for efficiency

9f8fe8c

dharjeezy requested a review from dmitry-markin November 29, 2025 18:20

dmitry-markin reviewed Dec 2, 2025

View reviewed changes

dharjeezy added 2 commits December 14, 2025 09:40

separate inbound and outbound streams

f26e25c

fmt

9c535ed

dharjeezy requested a review from dmitry-markin December 14, 2025 22:44

haikoschol reviewed Dec 17, 2025

View reviewed changes

	// Handle Outbound Responses (Ping is expected here)
	// Handle Inbound Pings

Repeat ping request periodically #416

Are you sure you want to change the base?

Repeat ping request periodically #416

Uh oh!

Conversation

dharjeezy commented Jul 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmitry-markin left a comment

Choose a reason for hiding this comment

Uh oh!

dmitry-markin commented Oct 21, 2025

Uh oh!

dharjeezy commented Nov 29, 2025

Uh oh!

dmitry-markin left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dharjeezy commented Dec 14, 2025

Uh oh!

haikoschol commented Dec 17, 2025

Uh oh!

haikoschol left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dmitry-markin left a comment •

edited

Loading

haikoschol left a comment •

edited

Loading