ipfs/kubo

The connection manager should treat LAN connection specially

Open

#6130 opened on Mar 26, 2019

View on GitHub
 (6 comments) (4 reactions) (0 assignees)Go (13,906 stars) (2,725 forks)batch import
help wantedkind/enhancementneed/analysisneed/community-input

Description

Version information:

go-ipfs version: 0.4.19

Type: enhancement

Description:

The connection manager currently treat indistinctly LAN and internet connection, even though they don't have the same cost, for all meaning of this term.

This means that a MDNS-enabled node might have its LAN connection dropped when the connection manager reach the high water mark, and be forced later to route through the internet for something that could be achievable locally, which is a bit silly. Also, nodes that are in the same local network usually are mode likely to require content from each others, be it because they are part of the same application or because users want to access the same content from different machine at home.

I'd like to suggest a smarter connection manager, that either:

  • don't drop local connection
  • treat specially local connections, with a dedicated low/high water mark

Contributor guide

Tech stack
go
Domain
backendinfrastructure
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Go programmingIPFS basicsNetworking fundamentals
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65
Research direction
Examine the connection manager implementation in the go ipfs codebase, likely in the 'core' or 'p2p' packages. The issue suggests two approaches: preventing dropping of LAN connections or using separate watermarks. Review existing logic for peer tagging (e.g., 'connmgr' package) and explore how to differentiate LAN peers (e.g., using private IP ranges). Consider the impact on MDNS discovery and existing tests.