种子内文件单独HASH、跨torrent共享文件成功过没有？成功过。
出过几个种子，于是特意试了下这个特性，混合种子A和B，两个包含相同的tracker；
B包含文件1234，和A内的文件HASH相同，在A已有百多人下载后新制作的未发布，拖入支持V2的客户端里，等待几个小时无进度，换客户端继续等待，仍无进度。相当于一个无人问津的死种无法从另一个热种里获取需要的文件。
也许是B没有足够的peer从DHT里获取相同文件的信息？于是又把B发布给公众，单独上传了4，123删掉，计划从A内获取。上传后也有百十个人下载了，Peer里也不乏支持v2的客户端，但等待多时仍未能从A里下载到123的任何进度。
上次文件共享成功是在种子C、D、E、F上传两天之后，新上传的种子G含CDEF里共有的文件X，在G开始做种后不久，CDEF都获取到了该文件。
这特性本来对冷种、死种、卡种是最好的，但第一阶段的测试里就发现显得过于理想化了。
1個讚
v2种子不具备这个功能
针对v2种子的特性BitTorrent v2 这篇文章介绍得比较完整
什么东西。我说和电骡一样的单文件单独HASH，v2 众多小改进里为数不多相对亮眼的功能了。也是你链接里提到的，自己都不看。
per-file hash trees
BitTorrent v2 not only uses a hash tree, but it forms a hash tree for every file in the torrent. This has a few advantages:
Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything. Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.All files will be aligned to pieces, which means there are implicit pad files after each file
This addresses a long-standing wish to more easily identify duplicate files, or finding multiple sources for files, across swarms .
wxhere15:
说的是不是下面这个功能？后续版本可以考虑支持
囊括了这么多协议咩，主要就是这个：
finding multiple sources for files, across swarms .
有的说这和可变种子相似，但我没看出来相似在哪里，网上有讨论，你们应该能看懂。
Bittorrent v2 Merkle hash seeding
Swarm merging
In addition, it opens up the door for peers to get the same file from multiple torrents. This is already technically possible today, as BiglyBT’s ‘swarm merging’ feature shows, but with unique file hashes, it’s easier and more reliable.https://torrentfreak.com/libtorrent-adds-support-for-bittorrent-v2-a-potential-game-changer-200912/
意思应该是在bt协议的框架内实现跨 torrent 传输
zhuxiaoying85309:
长效种子已经测试可以成功跨种子传输数据
这样一来长效种子其实就不算了
长效种子的逻辑更像eMule
现在的目标就是 跨torrent文件 传输相同的文件
以一个剧集为例 假设其共有20集 分两次放出
第一次放出10集 即1-10集
过了一个月 第二部分也放出了
现在希望在下载 1-20 的时候
BEP 38似乎是针对已经下载的文件进行识别防止重复下载的
而BEP 39 和 BEP 46 说的应该是 更新 torrent文件
之前下载的 1-10 的任务可以更新成1-20的任务
但这对没有迭代升级关系的种子来说就不适用了
比如两个用户A和B 分别创建了两个电影收藏种子
理想的情况应该是：
这些协议似乎都不能实现跨torrent传输
而且BEP 38 39 46 都处于草稿阶段
应该还没什么客户端支持
不过要添加对这些协议的支持最好和其他的客户端作者沟通一下
其实就是有最大的一个难题，因为每次发布种子后，A和B的种子特征码是不同的，B无法找到A的peer ip地址。http://www.bittorrent.org/beps/bep_0038.html
就算v2种子会提供每个文件的hash，但是也需要客户端去记录这些hash信息做成数据库
bolivia:
又从不具备这个功能变成一个难题了？
v2种子的这个分块hash主要是用于本地客户端去重节省空间，避免客户端重复下载数据，直接通过硬连接手段来与另一个其它种子已存在的文件链接起来，来节省传输流量，而不是跨种子实现互相上传下载，从你描述上来看是想要具备跨种传输的能力，所以说v2种子并不具备此功能。
打了很多又删了。唉，事实糊脸了还嘴硬，这次不光是天下皆醉你独醒了。
？删了干嘛，发出来啊
基于摘要的文件共享是唯一的，容易遭到封锁，蜜罐等
fy939
2024年02月29日03:50
16
v2目前只是单文件有唯一哈希，但是目前并没有支持发布到dht或是tracker，所以目前是不支持跨种传播，只是造了个基础让以后可以方便搞上这个功能
fy939
2024年02月29日04:00
17
这几个都不是跨种传输，38是本地相同数据合并，Biglybt有实现，叫种群合并，但不是硬链接是复制副本还是占两份空间，在下有相同文件的两个磁力，不用下两倍的数据大小，只用分别在两个磁力总共下一份数据大小就行。39 46是可变种子，可以实现种子的增量更新可以替代rss，应该参考自sync那些同步软件用非对称加密来搞公匙 私匙 把种子内容修改权限制在发布者手里