Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#5,355 0 comments 0 reactions 2 assignees View on GitHub

Maintainers usually reply within 2 days

@misaakidis is already working on this.

Since Sep 12, 2026.

Assessment

This issue has not been assessed yet.

Description

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.
Dominant language
Go
Stars
1.5k
Forks
390
Avg merge
2d 23h
Merged PRs (30d)
21

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ethersphere/bee

All issues in ethersphere/bee

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.