libp2p / libp2p/go-libp2p

swarm: simplify how we classify address as FD consuming

Open
#1,548 0 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

We need to classify addresses as FD/Non-FD consuming at two places:

  • Before we dial them. because we rate limit FD consuming addresses:

    • Relay addresses should be classified as Non-FD consuming for this purpose as the FD will be consumed later when the Relay code passes us the address of the Relay server.
  • When We partition the addresses into FD/Non-FD consuming and pass them to the dial code in two batches.

    • This ensures we attempt to dial the FD consuming addresses ONLY after we've exhausted all the FD consuming addresses.
    • However, for this purpose, we need to classify circuit relay addresses based on the address of the relay server so we can pass it to the appropriate batch.

Note: An FD consuming address for now is a TCP or WebSocket address.

See https://github.com/libp2p/go-libp2p-swarm/pull/212 and https://github.com/libp2p/go-libp2p-swarm/pull/212#discussion_r421816941 for the motivation.

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

No files or tests are named. Start by tracing the two address-classification sites described in the issue, along with the circuit relay dialing path and the motivation in PR #212. Done means relay addresses are treated as non-FD-consuming before dialing, while batching classifies them using the relay server address; TCP and WebSocket addresses remain FD-consuming.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.