rsync - 种子(和单个文件)是否有可证明的最佳 block ( block )大小？

Question

BitTorrent protocol不指定 block ( block )大小。这是留给用户的。 (我见过相同内容的不同种子有 3 种或更多不同的选择。)

我正在考虑提交 BitTorrent Enhancement Proposal这需要强制指定特定的 block 大小——既适用于整个 Torrent，也适用于单个文件(BTv2 (BEP 52) 指定 bs=16KiB)。

我发现唯一接近的是 Tridgell & Mackerras' technical paper 中的 rsync block 大小算法。 .他们的 bs=300-1100 B(# 字节不是 2 的幂)。

但是，种子 usually use bs=64kB–16MB(# bytes 是 2 的幂，比 rsync 大得多)整个 torrent(对于 BTv2，文件为 16KiB)。

指定的 block 大小不需要是常量。当然，它可能是事物散列大小的函数(就像在 rsync 中一样)。它也可以是文件类型的函数；例如可能有一些 block 大小更适合使部分视频/存档/等文件更有用。

另见 this analysis of BitTorrent as a block-aligned file system .

所以……

1. Torrent、通用文件或特定文件类型的部分用途的最佳 block 大小是多少？
2. BEP 52 中的 16KiB bs 从何而来？

Answer 1

block 大小和 block 大小不是一回事。

一 block 是散列到 v1 种子中的 pieces 字符串中的单元，每 block 一个散列。

block 是通过请求(ID 6)请求并通过片段(ID 7)消息传递的片段的一部分。这些消息基本上由 (piece number, offset, length) 元组组成，其中长度是 block 大小。从这个意义上说， block 在 v1 种子中是非常短暂的结构，但它们仍然很重要，因为下载客户端必须在内存中保留大量关于它们的状态。由于下载客户端可以控制请求大小，因此他们通常使用固定的 16KiB block ，尽管他们可以更灵活地做到这一点。对于上传客户端来说，复杂性并不重要，因为它们必须简单地提供 (piece,offset,length) 覆盖的字节，并且不保留任何进一步的状态。由于客户端通常实现消息大小上限以避免 DoS 攻击，因此 16KiB 也是推荐的上限。专门的实现可以使用更大的 block ，但对于真正不会发生的公共(public)种子。

对于 v2 种子，情况略有变化。现在有三个概念

• 通过消息发送的临时 block
• 片段(现在代表 merkle 树中的某个层)，在混合种子中需要 v1 兼容性，并且还作为 片段层 存储在信息字典之外以允许部分文件恢复
• 默克尔树的叶子 block

与 v1 种子相比，第一种类型基本上没有变化，但现在使用 16KiB 大小的 block 的动机更加强烈，因为这也是叶哈希大小。

片段大小现在必须是 2 的幂和 16KiB 的倍数，此限制在 v1 种子中不存在。

叶 block 大小固定为16KiB，在构造merkle树和交换消息ID 21(哈希请求)和22(哈希)时相关

What are optimal block sizes for a torrent, generic file, or partial usefulness of specific file types?

对于 v1 torrent，片段大小与文件大小相结合决定了元数据(又名 .torrent 文件)大小的下限。每个片段必须存储为 片段 中的 20 字节散列，因此较大的片段会导致较少的散列和较小的 .torrent 文件。对于 TB 级的 torrent，16KiB 的片段大小会产生约 1GB 的 torrent 文件，这对于大多数用例来说是 Not Acceptable 。

对于 v2 torrent，它会在根字典中产生类似大小的 piece layers。或者，如果客户端没有可用的 piece layers 数据(例如，因为他们通过 infohash 开始下载)，他们将不得不通过 h​​ash 请求消息检索数据，最终导致相同的开销，尽管在下载过程中更加分散。

Where did the 16KiB bs in BEP 52 come from?

16KiB 已经是大多数客户端的实际 block 大小。由于 merkle-tree 必须从一些叶子散列中计算出来，因此必须为这些叶子定义固定的 block 大小。因此，也为 merkle 树 block 选择了已建立的消息 block 大小。

The only thing I've found that's close is the rsync block size algorithm in Tridgell & Mackerras' technical paper. Their bs=300-1100 B (# bytes aren't powers of 2).

rsync 使用 rolling hash对于内容感知分 block 而不是固定大小的 block ，这是他们选择 block 大小的主要驱动因素。所以 rsync 注意事项不适用于 bittorrent。