宽带综合症候群#1 - 2022-4-19 00:25
サルビアマーロック
前传 BTv2協議
客户端 qBittorrent Enhance Edition 4.4.1.10->4.4.2.10 (BTv2)
备用客户端 Motrix FDM Transmission(BTv1)
测试所用BT HatBat 有效5天或50次下载，如果您也想测试请点击，不测试请勿消耗次数
本文内容为纯技术向问题，故隐去字幕组和作品名称。
一个多月前更新了qB，使用体验没有什么提升，卡顿和卡死却明显增多了许多。今天甚至出现了喜闻乐见的完全卡死无法启动客户端的情况。于是经历了重启、重装、清设置、清BT之后，终于发现了问题——两个BTv1+BTv2双协议种子，只要加载这两个种子之一就必定卡死无法启动，和曾经出现过的种子过多卡死的情况完全不同。
这两个种子一个是本季新番，来自某字幕组，包含文件为单文件800M。另一个是合集，是我亲手在自己的qB客户端生成的，包含十几个200M左右的文件，共约3G。
卡死原因不明，但这两个种子的唯一共性就是BTv1+BTv2双协议种子。
正常的双协议种子也有，单文件200K、多文件300M+100K，更奇形怪状的反而能正常使用。
回顾一下这一个多月来使用双协议种子的使用体验，只能说是相当糟糕。所谓的文件对齐就是为每个文件后面加上paddingfile，对齐到片段大小，和BitComet基本一样。没有BTv2支持的客户端有时甚至无法解析这种BT文件，在上传BT站时也有概率不认。
总之BTv2所宣传的优点，对齐——扯，安全——对于用途来说本就是伪命题，多文件下减小BT文件体积——在双协议模式下反而是超级加倍，没一个成真的。
这个技术虽然在理论上稍有优势，但实际上在过渡期的难用程度足以判他死刑了。
无论如何，我在下一次生成链接时，不会再选用双协议了。
客户端 qBittorrent Enhance Edition 4.4.1.10->4.4.2.10 (BTv2)
备用客户端 Motrix FDM Transmission(BTv1)
测试所用BT HatBat 有效5天或50次下载，如果您也想测试请点击，不测试请勿消耗次数
本文内容为纯技术向问题，故隐去字幕组和作品名称。
一个多月前更新了qB，使用体验没有什么提升，卡顿和卡死却明显增多了许多。今天甚至出现了喜闻乐见的完全卡死无法启动客户端的情况。于是经历了重启、重装、清设置、清BT之后，终于发现了问题——两个BTv1+BTv2双协议种子，只要加载这两个种子之一就必定卡死无法启动，和曾经出现过的种子过多卡死的情况完全不同。
这两个种子一个是本季新番，来自某字幕组，包含文件为单文件800M。另一个是合集，是我亲手在自己的qB客户端生成的，包含十几个200M左右的文件，共约3G。
卡死原因不明，但这两个种子的唯一共性就是BTv1+BTv2双协议种子。
正常的双协议种子也有，单文件200K、多文件300M+100K，更奇形怪状的反而能正常使用。
回顾一下这一个多月来使用双协议种子的使用体验，只能说是相当糟糕。所谓的文件对齐就是为每个文件后面加上paddingfile，对齐到片段大小，和BitComet基本一样。没有BTv2支持的客户端有时甚至无法解析这种BT文件，在上传BT站时也有概率不认。
总之BTv2所宣传的优点，对齐——扯，安全——对于用途来说本就是伪命题，多文件下减小BT文件体积——在双协议模式下反而是超级加倍，没一个成真的。
这个技术虽然在理论上稍有优势，但实际上在过渡期的难用程度足以判他死刑了。
无论如何，我在下一次生成链接时，不会再选用双协议了。
BTv2对每个文件单独计算哈希值且独占分块，应该更容易实现。
BTv2最大的问题是对于用户体验几乎没有任何提升，却增大了用户开销。
1. 共享者A制作种子A，共享者B制作种子B，两个种子包含一些相同的文件。
2. 下载torrent B可以获得共享者A的上传，下载torrent A也可以获得共享者B的上传。