Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

p2p: answer concurrent inbound ping streams

オープン
#719 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust

調査の方向性

Start with libp2p-ping 0.47 at src/handler.rs:349 and trace how Pluto’s pluto_p2p wiring handles inbound /ipfs/ping/1.0.0 streams. Compare the behavior with the concurrent streams described by the alpha test peers PingLoad scenario. Done means inbound ping streams are independently echoed with bounded concurrency while libp2p::ping continues providing outbound keepalive.

索引モデルが issue の本文から書いたものです。

説明

rust-libp2p's ping handler (libp2p-ping 0.47, src/handler.rs:349) holds a single inbound stream: each new /ipfs/ping/1.0.0 stream replaces it and drops the one in flight. go-libp2p serves each inbound ping stream in its own goroutine.

Impact: alpha test peers PingLoad (Charon and Pluto alike) opens one stream per ping from several concurrent pingers. Against a Pluto node most of those pings fail (recorded as zero RTTs), so the load test barely measures latency under load. Probe streams can also evict the remote's slot holding our own keepalive ping stream.

Possible fix: an inbound-only ping responder in pluto_p2p that echoes every negotiated /ipfs/ping/1.0.0 stream independently (bounded concurrency), with libp2p::ping kept for outbound keepalive.

Found while reviewing #718.

🤖 Generated with Claude Code

主要言語
Rust
スター
8
フォーク
5
平均マージ
3日 1時間
マージ済み PR(30日)
2

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NethermindEth/pluto のほかの issue

NethermindEth/pluto の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。