Interop Test: Ping Protocol Compatibility Between dotnet-libp2p and py-libp2p

Nobody has claimed this yet.

### Description

We're opening this issue to coordinate and document interoperability testing between dotnet-libp2p and py-libp2p, specifically focusing on the Ping protocol as a baseline test for stream establishment, connection negotiation, and basic transport reliability across implementations.

Objective

Verify that a node implemented in dotnet-libp2p can successfully send and receive libp2p/ping/1.0.0 messages with a node running py-libp2p, and vice versa.

This test will help confirm the following:

Transport-layer compatibility (TCP or WebSockets)

Multiaddr parsing and peer ID handshake

Stream multiplexer compatibility (e.g., mplex/yamux)

Secure channel handshake (e.g., noise)

Ping round-trip latency and correctness

Message framing and protocol negotiation compliance

Tasks

Launch py-libp2p node with Ping protocol handler

Launch dotnet-libp2p node and attempt to ping py-libp2p peer

Repeat test with roles reversed (ping from Python to .NET)

Capture connection logs, protocol negotiation traces

Identify any disconnects, hangs, or misinterpretations

Confirm round-trip ping response received within timeout

Compare behavior against libp2p spec: https://github.com/libp2p/specs/blob/master/ping/ping.md

### Motivation

The Ping protocol is the simplest and most fundamental way to verify that two libp2p nodes can:

Discover each other via peer IDs and multiaddrs

Establish a secure and multiplexed connection

Successfully exchange data over a protocol-defined stream

Ensuring interoperability between dotnet-libp2p and py-libp2p using Ping will:

✅ Serve as a sanity check that both implementations adhere to the libp2p protocol negotiation and transport specs.

🧪 Provide a testbed for debugging stream, muxer, and security protocol compatibility across languages.

🚀 Lay the groundwork for more complex cross-language use cases such as Identify, Relay, and DHT routing.

📦 Help maintain protocol parity as both libraries evolve (especially as py-libp2p is being revived and dotnet-libp2p gains adoption in .NET and Unity ecosystems).

🔧 Facilitate dev and CI pipelines where heterogeneous libp2p nodes are used in the same testnet or simulation.

Validating Ping interoperability is a low-complexity, high-value milestone in achieving full multi-language compatibility within the libp2p ecosystem.

### Requirements

To validate and ensure Ping protocol interoperability between dotnet-libp2p and py-libp2p, the following functional and technical requirements must be met:

1. Ping Protocol Implementation
Both implementations must correctly implement the libp2p/ping/1.0.0 protocol as specified in the [Ping Spec](https://github.com/libp2p/specs/blob/master/ping/ping.md).

The Ping handler must respond with a correct echo of the received message within the required timeout window.

2. Transport Compatibility
The nodes must be able to initiate and accept connections over a shared transport, ideally TCP.

Support for listening and dialing over multiaddrs like /ip4/127.0.0.1/tcp/PORT must work in both directions.

3. Secure Channel Handshake
A secure channel (e.g., Noise or TLS) must be successfully negotiated between the two peers.

Each node must validate the peer ID derived from the remote node’s public key (if required by the chosen security transport).

4. Stream Multiplexer Support
A compatible stream multiplexer (e.g., mplex) must be selected and function correctly.

Ping messages must be sent and received on a properly opened stream on the correct negotiated protocol.

5. Protocol Negotiation
The initiating peer must negotiate libp2p/ping/1.0.0 using multistream-select.

Both implementations must handle protocol negotiation using the correct framing and handshake sequence.

6. Bi-Directional Testing
It must be possible to:

Send a Ping from dotnet-libp2p to py-libp2p and receive a valid Pong.

Send a Ping from py-libp2p to dotnet-libp2p and receive a valid Pong.

7. Logging and Observability
Both nodes must log the following clearly:

Peer connection events

Protocol negotiation events

Ping sent and Pong received events with latency

Errors or disconnects (if any)

8. Failure Recovery and Timeouts
If the remote peer fails to respond, the Ping stream must timeout gracefully and clean up resources.

Any connection errors or protocol mismatches must be logged with descriptive diagnostics.

9. Reproducible Test Setup
A reproducible test script or instructions must be provided that allows other developers to replicate the test.

It should include:

Build/run instructions

Multiaddrs used

Expected output

Logs from both ends

### Open questions

_No response_

### Are you planning to do it yourself in a pull request ?

Maybe

Start by reading the libp2p Ping specification and reviewing the existing py-libp2p and dotnet-libp2p node setup. Run both nodes over a shared TCP multiaddr, test Ping in both directions, and capture connection and protocol-negotiation logs. Done means both peers exchange valid Ping/Pong messages, handle timeouts and disconnects, and have reproducible setup instructions with expected output.

Written by the indexing model from the issue text.