UPnP port mapping should be regularly attempted, not only at startup

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

メンテナーはふだん 3 日以内に返信

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
go
領域
networking

調査の方向性

Start by locating Bee’s startup UPnP port-mapping setup and reading how the UPnP service handles repeated mapping requests. Then determine where periodic retries would fit and what existing tests cover this behavior. Done means mappings are retried after startup so external reachability can recover when the UPnP service becomes available again.

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

説明

seen
Summary

my upnp service may become unresponsive (miniupnp in openwrt). when i notice i restart it, but seems like i also need to restart all my bee nodes, because it seems to only attempt (?) setting up the upnp mapping at startup.

i waited about 10 mintes only before restarting the bee nodes.

Motivation

make bee nodes' external reachability more reliable.

Implementation

i'm no expert neither of golang nor upnp.

maybe it's as simple as moving the setup code from the initialization into a periodic thread?

Drawbacks

i'm not sure whether the upnp API is smart enough for such a use-case (i.e. gracefully handling when the same port map is requested periodically).

主要言語
Go
スター
1.5k
フォーク
390
平均マージ
2日 22時間
マージ済み PR(30日)
24

環境構築

はじめの一歩

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

ethersphere/bee のほかの issue

ethersphere/bee の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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