Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

DCUtR (Direct Connection Upgrade through Relay) for non-reachable NAT-ed peers

Aperta
  • Qualcosa non va?
#5,355 0 commenti 0 reazioni 2 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@misaakidis ci sta già lavorando.

Dal 12/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

feature seen
Summary

Currently, the Swarm overlay places disproportionate structural load on inbound-reachable (publicly connectable) nodes to maintain topology health and indirectly connect NATed peers.

Introducing libp2p DCUtR (Direct Connection Upgrade through Relay) would allow two initially non-reachable Bee nodes to upgrade from relayed to direct connections when possible, reducing long-term reliance on public nodes and improving stability, performance, and fairness of the network.

Motivation

Swarm functions with outbound-only nodes, but this leads to:

  • reduced connectivity entropy, lower peer diversity,
  • traffic concentration on reachable nodes, causing higher impact from churn.
  • pull syncing practically requires at least one reachable anchor node in a neighborhood; DCUtR can release this requirement by enabling unreachable peers at the same depth to connect directly.

DCUtR does not eliminate the need for reachable nodes, but reduces the network's structural burden by shortening relay lifetimes and creating more direct peer edges.

For users:

  • More effective peer connectivity → more routing paths → higher chance of finding a fast, available responder
  • Less jitter and improved latency → More predictable UX under load (e.g. less fluctuation in stream consumption.)

For node operators:

  • Better discoverability despite NAT → more opportunities to serve bandwidth
  • Improved pull-sync robustness → lower hardware and bandwidth requirements
  • More stable peer sets even without a public IP
  • Relayers economically compensated via SWAP for negotiation traffic

For the network:

  • More evenly distributed connectivity graph
  • Reduced dependency on a small subset of public nodes → improved resilience to churn and localized failures
  • Better long-term scalability of topology maintenance
Implementation

Use existing peer connections as temporary relays for DCUtR signaling. Attempt direct connection upgrade after direct connection failure.

  1. SWAP accounting

    • Relay-forwarded DCUtR signaling traffic must be accounted
    • Relayers should be compensated for bandwidth used during negotiation

  2. Fallback behavior

    • Attempt DCUtR after direct connection failure.
    • Use existing inbound-reachable peer connections as temporary relays for DCUtR signaling. If the target node is not connected to any of the reachable peers then log this out.

  3. Topology changes

    • Re-evaluate restrictions that discourage storage or forwarding on non-reachable nodes, e.g.: in kademlia or push syncing

  4. Testing requirements

    • test environment under partial DCUtR success with no reachable node in one neighborhood
    • topology stability tests (with measuring tail latency under high concurrency)
    • pull-syncing, retrieval and upload correctness
    • relay accounting correctness
Drawbacks

  • Not a universal solution

    • DCUtR does not work reliably with:
      • symmetric NATs
      • multi-layer NAT / CGNAT
      • relayer located behind the same NAT as one peer

  • Added complexity

    • Increased complexity in p2p, accounting, and topology subsystems
    • Harder to reason about emergent connectivity behavior

  • No benefit for browser clients

    • Browsers cannot open raw TCP/QUIC sockets
    • DCUtR does not improve browser connectivity

  • Reachable nodes still necessary

    • Bootstrapping
    • Browser access
    • Even DCUtR requires that for initiating connections
    • However, it reduces pressure on them and require less from them.
Lingua principale
Go
Stelle
1.5k
Fork
390
Merge medio
2g 12h
PR unite (30g)
18

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ethersphere/bee

Tutte le issue di ethersphere/bee

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.