文档目录

下载协议

eD2K

通过 ed2k:// 链接从电驴网络下载,支持服务器与 Kad 找源及全程哈希校验。

FluxDown 内置 eD2K(eDonkey2000,俗称”电驴”)客户端——把 ed2k:// 链接粘贴进新建下载对话框,就能像普通任务一样下载。客户端为纯下载设计:只从网络获取文件,不做分享与上传,因此没有共享目录管理和上传配额的概念。

ed2k:// 链接

FluxDown 接受标准的文件链接格式:

ed2k://|file|<文件名>|<字节大小>|<eD2K 哈希>|/

链接本身携带文件名、精确大小和内容哈希,新任务开局即拥有全部必要信息;部分站点附加的扩展段(如 |h=...||s=...|)会被容忍并忽略。使用传统中文编码(GBK)的文件名也能正确解码。

找源

FluxDown 通过两条互补渠道寻找持有文件的对等端,默认都已开启:

  • eD2K 服务器 —— 客户端向社区服务器列表查询。列表由「设置 → eD2K 服务器」中的两部分合并而来:手动填写的服务器列表(每行一个 host:port),以及定期抓取社区维护 server.met服务器订阅(每 24 小时刷新,支持「立即更新」)。两者自动合并去重。
  • Kad DHT —— 去中心化查询,即使所有服务器都挂掉或无法访问也能找源。开关为「Kad DHT 找源」。

如果找不到任何源,FluxDown 会以约一分钟为间隔重试几次,之后才把任务标记为失败——冷门文件可能需要多轮尝试才能定位。

HighID 与端口映射

只有当你的 eD2K 端口可以被外部连入时,对等端才能回连你(eD2K 术语称 HighID)。若路由器支持,FluxDown 会通过 UPnP 自动完成端口映射(「UPnP 端口映射」,默认开启)。「监听端口」设置决定 TCP/UDP 端口,默认值 0 表示由系统自动选择。LowID 状态下仍可下载,只是能为你供源的对等端更少。

完整性校验

eD2K 本身就是围绕内容哈希构建的网络,FluxDown 在每个层级都做校验:

  • 文件按标准 9.28 MB 分块,每块下载完成的瞬间即做哈希校验。
  • 发来损坏数据的对等端会在本任务内被拉黑;校验失败的块会换其他对等端重试(每块最多 5 次)。
  • 最后一块完成后,整个文件会从磁盘重新读出并对照链接中的哈希做终验,通过后才改名为最终文件——完成的 eD2K 下载与链接逐比特一致。

并发与断点续传

多个分块并行下载,各自使用独立的对等端连接。并发数由任务的线程数设置控制:默认 4 个并行对等端,上限 8。每块的进度都记录在本地数据库中,暂停、退出应用或崩溃都不会丢失已校验的分块——任务会从中断处精确恢复。

相关设置

设置项位置
服务器列表设置 → eD2K 服务器
服务器订阅设置 → eD2K 服务器
Kad DHT 找源设置 → eD2K 服务器
UPnP 端口映射设置 → eD2K 服务器
监听端口设置 → eD2K 服务器
默认线程数(并行对等端数)设置 → 下载

限制与常见问题

为什么一直卡在”找不到源”? 文件可能在网络上很冷门甚至已经死链。确认服务器订阅最近更新过(「设置 → eD2K 服务器」会显示服务器数量与上次更新时间)、Kad 已开启,然后让任务继续重试——eD2K 上的找源确实可能需要几分钟。

下载的同时会上传吗? 不会。客户端是严格的纯下载实现,不会向网络回传文件。

速度比同体积的 HTTP 下载慢。 这是 P2P 传输的固有特性:吞吐取决于持有文件的对等端数量及其上传能力,而不只取决于你的带宽。争取到 HighID(见上文)通常会有改善。

这页文档有问题?