Connection Management and definable Topologies
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 20/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
调研方向
首先查看当前的 libp2p Connection Manager，以及本提案中描述的拓扑概念。阅读链接的 Genet paper 和 go-ipfs peer-set issue 以了解背景；只有在拓扑注册、连接限制和主动管理方面形成一致的 v2 设计后，才算完成，而不是进行一个小型的孤立修改。
由索引模型根据 Issue 内容生成。
描述
I've started thinking more about Connection Management for the v2 spec. Adding my thoughts here, although they are still very raw and incomplete. The general approach is to leverage allocable overlays/Topologies to create a proactive approach to Connection Management, instead of the current reactive approach.
Connection Management
Topologies
Multiple systems that integrate/leverage libp2p create different Network Topologies. In most instances, these are generated by the natural usage of those systems, for example the DHT and Gossipsub. In systems like IPFS, it is desirable for nodes to create custom Topologies to better support certain network needs. For example, JS IPFS nodes running in the browser may have a high dependency on Preload nodes to store their content in instances where they cannot stay online.
Bootstrap nodes are another instance of a network Topology. While their connectivity may be short lived, they serve as a critical role in remote network discovery.
It is desirable for nodes to be able to persist these Topologies in the event they go offline. When the node comes back online, being able to rejoin their Topologies quickly, will enable users to resume their normal activities in a shorter period of time.
Topology Interface
Creating an interface for Topologies may enable us to support a broad range of implementations. Users would be able to define custom Topologies for their applications, such as High Priority nodes. Subsystems of Libp2p could leverage the interface to create and evolve their own Topologies. Topologies could be created to control their limits. For example, too many nodes attempting to add IPFS Gateway nodes to their Priority Topology could be denied, or directed to other high availability nodes in the Gateway nodes Sibling Topology.
Connection Manager
The current libp2p Connection Manager is reactive. When connection limits are exceeded, connection pruning takes place. While the Connection Manager attempts to take a best guess pass at pruning, it can currently cause starvation in subsystems if any one system is leveraging the majority of connections.
If the Topology system was leveraged, it could be made to request limits from the Connection Manager for each Topology. Each request could also define the types of connections being requested. For High Priority nodes these could be permanent connections, where as the DHT might request a mix of permanent connections, to maintain a consistent DHT overlay, and something akin to a burst set (many short lived connections).
Registration of Topologies with the Connection Manager would enable the Connection Manager to make more informed decisions when pruning, and in addition, would enable the Connection Manager to deny requests. As subsystems are made to dynamically improve over time, future iterations of this registration may include a "repurchase", where systems may request additional connections if they are being heavily used. In addition, the Connection Manager could potentially, proactively loan or give an allotment of connections if it sees the system being starved.
Benefits
- User and subsystem defined/managed Topologies
- Topology limits requested from the Connection Manager
- Enable researches to define Topologies such as Genet
- Give users greater control over peer sets ipfs/go-ipfs#6097
- 主要语言
- 没有语言数据
- 星标
- 38
- 派生
- 2
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
libp2p/notes 的其他 Issue
-
难度 5/5 一周以上 新手友好度 20/100
-
难度 5/5 一周以上 新手友好度 20/100
-
DHT
难度 5/5 一周以上 新手友好度 25/100
-
enhancement
难度 5/5 一周以上 新手友好度 25/100
-
难度 5/5 一周以上 新手友好度 25/100
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 85/100
vllm-project/vllm#59268 ·
维护者通常 1 天内回复
-
status:in-linear status:team-assigned team:cats
难度 2/5 1-3 小时 新手友好度 90/100
维护者通常 1 天内回复
-
kind/feature
难度 2/5 1-3 小时 新手友好度 68/100
kubernetes-sigs/kubespray#13595 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
kvcache-ai/Mooncake#4390 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
BrighterCommand/Brighter#4477 ·
维护者通常 1 天内回复