Sai*_*Sai 3 rsync bittorrent file-transfer
BitTorrent协议不指定块（块）大小。这是留给用户的。（我见过相同内容的不同 torrent 有 3 个或更多不同的选择。）
\n我正在考虑提交BitTorrent 增强提案，该提案需要为整个 torrent 以及单个文件（其中BTv2 (BEP 52)）强制指定特定的块大小 \xe2\x80\x94指定 bs=16KiB）强制指定特定的块大小 \xe2\x80\x94 。
\n我发现唯一接近的是 rsync 块大小算法Tridgell & Mackerras 技术论文中的 rsync 块大小算法中的 rsync 块大小算法。它们的 bs=300-1100 B（# 字节不是 2 的幂）。
\n然而，Torrent通常 使用bs=64kB\xe2\x80\x9316MB（# bytes 是 2 的幂，比 rsync 大得多）（对于 BTv2，文件使用 16KiB）。
\n指定的块大小不需要是常量。当然，它可能是事物散列大小的函数（就像 rsync 中的那样）。它也可以是文件类型的函数；例如，可能有一些块大小更适合使部分视频/存档/等文件更可用。
\n\n所以\xe2\x80\xa6
\n块大小和块大小不是同一回事。
片段是pieces在 v1 种子中散列到字符串中的单位，每个片段一个散列。
块是片的一部分，通过请求（ID 6）请求并通过片（ID 7）消息传递。这些消息基本上由元组组成，(piece number, offset, length)其中长度是块大小。从这个意义上说，块在 v1 种子中是非常短暂的构造，但它们仍然很重要，因为下载客户端必须在内存中保留有关它们的大量状态。由于下载客户端可以控制请求大小，因此他们通常使用固定的 16KiB 块，尽管他们可以更灵活地做到这一点。对于上传客户端来说，复杂性并不重要，因为它们必须简单地提供 所覆盖的字节(piece,offset,length)并且不保留进一步的状态。由于客户端通常会实施消息大小上限以避免 DoS 攻击，16KiB 也是建议的上限。专门的实现可以使用更大的块，但对于公共种子来说，这并没有真正发生。
对于 v2 种子，情况略有变化。现在有3个概念
piece layers信息字典之外，以允许部分文件恢复与 v1 种子相比，第一种类型本质上没有变化，但现在使用 16KiB 大小的块的动机更加强烈，因为这也是叶哈希大小。
现在，片段大小必须是 2 的幂和 16KiB 的倍数，v1 种子中不存在此限制。
叶子块大小固定为 16KiB，在构建 Merkle 树和交换消息 ID 21（哈希请求）和 22（哈希）时相关
种子文件、通用文件或特定文件类型的部分用途的最佳块大小是多少？
对于 v1 torrent，片段大小与文件大小相结合决定了元数据（也称为文件）大小的下限.torrent。每个片段必须以 20 字节的哈希值形式存储在 中pieces，因此较大的片段会导致较少的哈希值和较小的.torrent文件。对于 TB 级 torrent，16KiB 的片段大小会产生约 1GB 的 torrent 文件，这对于大多数用例来说是不可接受的。
对于 v2 种子，它会piece layers在根字典中产生类似大小的结果。或者，如果客户端没有piece layers可用的数据（例如，因为他们通过 infohash 开始下载），他们将不得不通过哈希请求消息检索数据，最终导致相同的开销，尽管在下载过程中分散得更多。
BEP 52 中的 16KiB bs 从哪里来？
16KiB 已经是大多数客户端事实上的块大小。由于默克尔树必须根据一些叶散列计算，因此必须为这些叶定义固定的块大小。因此，默克尔树块也选择了已建立的消息块大小。
我发现唯一接近的是 Tridgell & Mackerras 技术论文中的 rsync 块大小算法。它们的 bs=300-1100 B（# 字节不是 2 的幂）。
rsync 使用滚动哈希来进行内容感知分块，而不是固定大小的块，这是其块大小选择的主要驱动力。因此 rsync 的注意事项不适用于 bittorrent。