libp2p / libp2p/go-libp2p

impossible to observe holepunch using Connectedness event when using an unlimited relay

Open
#3,101 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
6.9k
Forks
1.3k
Avg merge
13d 21h
Merged PRs (30d)
1

Description

I'm trying to observe the establishment of a connection from relayed to direct (using DCuTR).

Initially I thought that I could use the `Connectedness`' `Limited` state for that. This works find when using a limited relay, but it fails for an unlimited relay:
https://github.com/libp2p/go-libp2p/blob/4e85c9611ae6f5c012d088b0119e825eae0b4af6/p2p/protocol/circuitv2/client/dial.go#L181-L182

A connection via an unlimited relay is considered `Connected` right away, and the establishment of a direct (hole-punched) connection doesn't trigger another event, since we're already "connected".

The best resolution I could come up with is the following: Split the `Limited` state into two: `Relayed` and `RelayedUnlimited`. This is a breaking change obviously, but at it's made explicit by the removal of `Limited`, forcing users of the library to rethink their logic.

Contributor guide

No contributing guide indexed for this repository

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.

Research direction

Start with p2p/protocol/circuitv2/client/dial.go at the linked lines and trace how unlimited-relay connections are classified and how Connectedness events are emitted. Reproduce relaying followed by DCuTR hole punching, then determine an API-compatible or explicitly breaking way to distinguish relayed and direct states. Done means callers can reliably observe the transition to a direct connection and the behavior is covered by tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.