之前一直以为是保存在torrent文件内的，直到今天下了个v2种子发现没有ed2k链接了，遂自己生成并填了进去，再手动保存种子，但是导入另一个客户端后依旧没有，使用种子编辑器查看保存的种子发现的确没有。
使用普通v1种子做实验发现：添加种子后若不立即开始，ed2k链接是没有的；在开始任务后ed2k链接才会出现。查看电驴插件内的日志并未发现搜索请求，说明并不是从电驴网络获取的。可以做实验验证：关闭电驴插件，添加一个新任务，任务开始前在文件列表中右键选择设置ed2k链接弹出的框内应该是空的；开始任务后再次操作框内出现ed2k链接。
所以1：难道这个ed2k链接并不是从p2p网络而是从某个中心化的服务器获取的？如果后续这个服务器关闭了这个功能就会失效？2：是否能对v2种子添加此功能的支持？
1個讚
ed2k链接应该是计算出来的 即计算文件的哈希值
可能是v2种子添加的时候没有触发 计算ed2k链接
ed2k链接应该是计算出来的
我的意思是在本地还未下载文件的时候是从哪个渠道提前得到的ed2k链接
意思是说文件还没有下载完成的时候？
即刚添加任务的时候没有ed2k链接？
但是开始任务后就有了 而且这个文件还没有下载完？
是的，根据我观察到的现象看就是这样。甚至在一个peer都没连上的时候就能看到ed2k链接了。
当然我相信全网还没出种的种子肯定是没有的，你可以找一个你从未下载过的热门历史种子做个测试。
确实 如果是自己做的测试种子是不会有的
v1
确实会出现 之前没有ed2k链接 但是开始任务后出现链接
但是在eMule的日志中有显示新增下载 可能还是要依靠ed2k 网络
你可以试试把电驴插件相关文件全部删掉，依然能够获得ed2k链接。虽然界面显示插件已禁用，但是通过“设置ed2k链接”的选项还可以看到。
eMule新增下载的前提是拥有ed2k链接，下载肯定是发生在获得链接之后的。
确实是这样的 即使没有eMule插件也可以获取到
经过实验发现是 长效种子的原因 关闭长效种子就获取不上了
可能长效种子的服务器起到了类似于eMule 中的 kad服务器的作用
长效种子的很多特性于 eMule 的kad十分相似
那就突然明白了 
长效是依赖彗星的服务器实现的，那么这个问题的回答就是yes
那就得等待长效服务器的服务端适配对v2哈希的索引了，希望能够尽早实现吧，感觉原理应该差不了多少
应该是对 SHA-256 的支持
之前用的都是sha1 eMule 的 ed2k 和长效种子都是
可能不会再服务器上修改了
也许在本地计算会成为可能 毕竟v2种子种包含单个文件的哈希值
而不仅仅只有分块的
长效种子( Long-Term)，和电驴( ed2k)的下载链接存储在torrent文件中，可以用记事本打开文件来查看
如果torrent文件中未包含时，客户端在下载该BT种子任务完成后会进行二次校验进行生成ed2k与长效种子的hash值并且提交给tracker服务器（ 相关高级选项为：bittorrent.hash_check_for_ltseed ），此时他人下载相同的BT种子时，就算这个BT种子并没有包含hash，但是可以通过tracker服务器来获得hash信息，从而让客户端立即触发长效种子下载
v1 v2种子都具备这个特性，可以观察torrent文件来验证
我做了一些测试，一些新种内确实包含了ed2k链接，但是老种即便我使用最新的彗星下载并在客户端内看到了ed2k链接，手动保存出的种子内也有saved by Bitcomet2.04字段，但是文件内并没有ed2k链接。小樱知道怎么让ed2k链接包含在种子文件内吗？
如果你同时保了两个拥有相同文件的种子，可以观察到这两个种子的长效种子上传速度完全一致的现象。这说明长效种子是以文件为单位独立于bt种子/magnet链接的，是通过比特彗星的服务器实现的，跟tracker服务器应该没多少关系。跟tracker通讯的内容都是bittorrent标准，不太可能包含ed2k之类种子内单文件hash的信息。
这个是在制作种子文件的时候需要勾选长效种子和ed2k两个选项，如果使用制作种子文件的bt客户端不支持，那么生成出来的torrent文件就不会包含这些hash信息
指的是BT软件提供的官方tracker服务器，用作支持长效种子，这个过程是私有协议的tracker（类似PT需要passkey才能进行接入tracker，所以登录彗星账号后可以获得更多的长效种子数量），并不是传统形式的公共tracker任何人均可使用，可参考下方长效种子的bep协议规范
在启用专家模式后，客户端左侧处，可以看到完整的长效种子列表
长效种子实现主要应该是这几个bep协议规范，可以读一下
http://www.bittorrent.org/beps/bep_0017.html
http://www.bittorrent.org/beps/bep_0019.html
http://www.bittorrent.org/beps/bep_0038.html
http://wiki.bitcomet.com/inside_bitcomet#:~:text=this%20topic.-,Hash%20Checking%20Conditions,-BitComet%20will%20perform
http://wiki.bitcomet.com/long-term_seeding
之前找libtorrent开发者聊过，由于实现长效种子功能需要bt客户端官方开发者提供服务器部署tracker，这种长效种子方案没有去中心化实现，所以由于服务器成本原因，目前其它bt软件还未支持上长效种子功能。
这个说法有一些不准确
根据维基百科的描述，ed2k链接的核心信息ed2k Hash，也是比特彗星提供的ed2k链接内的hash，是基于md4算法得到的。
v1种子的infohash算法基于sha-1，v2种子的multihash算法基于sha-256，这些是对应于单个种子的。长效服务器的作用更类似于建立单个种子的哈希与种内文件ed2k链接集合的联系，那么实现对v2种子的支持理论上再加个表/库把哈希格式改成multihash即可。
这个说法也不太准确，KAD是基于DHT技术的分布式去中心化网络。应该说更类似于中心化的ed2k服务器，只不过是提供给彗星用户独享的那种。
在上面发的相关页面里，也可以完全了解到长效种子等是如何实现的，看完文章后基本就能知道是什么回事了，例如这一段话，就是我上面说的tracker实现
LT-Seeding clients use a server (the equivalent of a tracker, in the BitTorrent protocol) for querying and finding peers (LT-Seeds) for the tasks which have LT-Seeding enabled. This is done by using a unique LT-hash which is being computed for every file of the task.
只有制作种子的时候才有啊…那意味着除了手工修改torrent文件没有什么便捷的办法为已有的torrent附加ed2k链接了呗。毕竟如果重新制种信息哈希就变了，没办法对原种提供帮助。
理论上迅雷的某些特性也可以算是长效种子 
很容易观察到迅雷在下一些老种的时候是基于文件而不是基于pieces下载的。不过从这方面来看彗星也算是“比肩迅雷”的优秀bt软件了 
可以按迅雷的一些说法宣传，比如“智能解决死链”之类的
看了一下确实不是sha1
在长效种子中应该是有文件而无任务
启用专家模式后可以查看长效分享的文件 其于eMule 的文件共享列表很相似
对 说错了 是 ed2k服务器 kad是去中心化的 ed2k不是 可能更像是私有ed2k服务器
其实迅雷也是有内置eMule客户端的较老的版本是有eMule选项设置的
差不多，但是实现方案还是不一样，比特彗星是基于bep协议规范开发，只有任务列表存在BT任务的时候，并且任务启用了开关才会进行长效上传，同时优先保证BT网络传输，对长效种子自动限速。
这也是为什么连接到长效下载的时候，，可能有时候只有几KB的速度，过两个小时在下载发现又快起来了，因为对方在给BT网络上传中，长效上传被自动限速了
迅雷是付费机制，客户端是扫盘上传，在客户端内没有任何任务列表的时候，依旧会对某个文件产生上传速率，并且其它客户端需要付费才能接入这个P2P网络，或者免费试用60秒之类，同时迅雷会提供网心云矿工来充当P2P服务器，帮助付费用户提供下载，所以一般情况来说，相同的资源下载迅雷反而可以获得更好的速率，因为网心云上保种的人多。
应该是通过长效种子服务器获取的
猜测：
当有用户下载完成后会向长效种子服务器汇报
汇报内容可能既包括用于识别bittorrent的 sha1 哈希值 用于确定 bt任务
同时还包含了 这些文件的 md4 哈希
当另一个用户添加bt任务后向 长效种子服务器发起查询
根据sha1 匹配到了的bt任务
同时获得的其中每个文件的 md4值
于是本没有的ed2k链接被补全了
BitComet独有的长效种子功能，一方面可以从完成度为100%用户那里获得数据，另一方面在网络上寻找镜像服务器获得数据，这样能大大增加下载速度。但在增加下载速度的同时，你也要上传数据给其他用户。对于发布时间比较久的BT任务，很多时候都会遇到没有种子的情况。没有种子，自然就不能完成任务。现在有了长效种子功能够让完成度为100%用户后台做种，省去了补种的麻烦。 【长效种子下载不支持私有种子！】
For .torrent files which don’t contain the LT-hash(es) (i.e. created with other torrent makers), the first BitComet client in the swarm which finishes the download, will calculate the LT-hash(es) and upload them to the server, making them available to the other BitComet peers, so that they may search for LT-Seeds for that task at any time later.【Only suitable for BitComet Client】
Due to the fact that in LT-Seeding protocol resources are being identified using a hash value that is being calculated per file this means that through LT-Seeding you could even get the same files from peers belonging to another torrent swarm (i.e. a torrent swarm using a .torrent file with a different info-hash than the BitTorrent swarm for which you’re currently being a peer), as long as at least some files of the alternative torrent are identical (on a binary level, thus yielding the same file-hash) to the ones of your current torrent and LT file hashes have been uploaded to the server for those files.
This is another way how BitComet may help revive or keep alive, dead or poorly seeded torrents.
很清晰的说明，长效的工作流程应该也跟这个类似，把返回的ed2k链接换成长效用户的ip和端口就能下载了。不过有一些说法还是不能混用的，比如ed2k与md4、bittorrent的infohash与sha1：
我写过计算ed2k链接的程序，ed2k-hash并不直接是文件的md4摘要值，而是分块计算，合并各个分块的哈希后再次哈希得到的，所以ed2k-hash与md4不能直接等同。同理bittorrent infohash也不是直接对torrent文件做sha1得到的，而是取其中的一部分，所以你可以在torrent文件里修改tracker、增加字段而不影响文件的下载。