FluxDown eD2K 电驴下载 — 内置客户端、Server + Kad 发现、9.28MB 分片哈希校验
为什么一个现代下载器还要做 eD2K
eDonkey2000 网络（电驴/骡骡）在 2026 年仍然活跃——大量中文稀缺资源、老电影、稀缺文档只能在 Kad 网络上找到。传统上用 eMule、aMule 之类专用客户端，但这类客户端功能重、界面旧、安装麻烦。FluxDown 把 eD2K 做成了引擎内置的一个协议，和 HTTP/BT/HLS 混在一个队列里跑。
客户端定位：下载专用
FluxDown 的 eD2K 客户端只下载不分享——不会把你已下载的文件共享回 Kad 网络。这意味着没有上传管理、没有积分体系、没有文件库管理。它就是个纯粹的 ed2k:// 链接拉取器。
ed2k:// 链接格式
标准电驴链接格式：
ed2k://|file|<文件名>|<字节大小>|<eD2K 哈希>|/链接本身已经携带了文件名、精确大小和内容哈希——所以一个新 eD2K 任务从诞生起就知道最终文件应该是什么样，这比 HTTP 好。有些站点会在链接后面追加 |h=...| 或 |s=...| 字段，FluxDown 能容忍并忽略它们。中文传统 GBK 编码的文件名也能正确解码。
来源发现
eD2K 找来源有两条互补通道，默认都开：
| 通道 | 说明 | 默认 |
|---|---|---|
| eD2K 服务器列表 | 向一组社区维护的服务器查询有这个文件的 Peer | 开，自动从订阅拉最新列表 |
| Kad DHT | 去中心化的 Kademlia 网络节点发现，服务器全挂时也能找 | 开 |
「设置 → eD2K Servers」里可以手动填服务器列表（每行一个 host:port），也可以开 Server 订阅（默认 24 小时刷新社区维护的 server.met 列表）。两者合并去重后生效。
HighID / LowID / UPnP
eD2K 术语里的 HighID = 你被 Peer 反向连接到了（路由器端口映射成功）；LowID = 只有你能连别人，别人连不上你。LowID 能下但能服务你的 Peer 变少。
FluxDown 默认开 UPnP 自动端口映射——路由器支持的话自动开监听端口（默认 0 = 系统自动选）。关掉 UPnP 或路由器不支持就会变成 LowID。
完整性校验
这是 eD2K 比 BT 做对的地方——逐片哈希校验：
- 文件切成固定 9.28 MB 的 part。
- 每下载完一个 part，立即对该 part 做哈希校验。
- 给你发了坏数据的 Peer 拉黑（本任务内不再用）。
- 失败的 part 换其他 Peer 重试（最多 5 次）。
- 全部 part 下载完后，再读一遍完整文件验证总哈希——保证成品逐字节匹配链接里声明的。
为什么 BT 不做这个？BT 也有 piece 哈希校验，但 BT 的 piece 大小由种子决定（256 KB – 4 MB 不等），没有 eD2K 这么统一。eD2K 的 9.28 MB part 是协议层固定的，所以客户端可以在 part 级别做严格校验。
并发与恢复
默认 4 个并行 Peer，上限 8。恢复机制和 HTTP/BT 一样——SQLite 记录每个 part 的完成状态，重启后只补未完成的 part，已校验的不会重拉。
常见问题速查
- 卡「no sources」 — 可能资源确实稀有，也可能 Server 列表过期或 Kad 被防火墙挡（见 eD2K 无来源）。
- 速度比 HTTP 慢很多 — 正常，eD2K 是 P2P，速度取决于有多少 Peer 有这个文件。
- 会上传吗 — 不会，FluxDown eD2K 只下载。