bittorrent - 当它们重叠时如何将 block 分成一 block

Question

一些输入我正在寻找构建一个简单的最小 bittorrent 客户端。
我现在阅读协议(protocol)规范 2-3 天。

到目前为止，这是我对它的理解。假设 torrent 有 片长的 26000 bytes并根据非官方规范 block 大小 是 16384 .像这样的东西。


现在根据请求 block 消息看起来像这样

piece 0 
block offset 0
block length 16484

到现在为止还挺好。

现在，对于在第 0 block 和第 1 block 中重叠的下一个 block ，请求应该是什么样的

piece 0  ## since the start of byte is in piece 0 use piece 0 instead of piece 1
block offset 16384
block length 16384

现在在接收端，我需要重新创建 26000 字节的片段，以便我可以将其与片段(哈希)进行比较，以匹配片段的正确性。

我的理解正确吗？

另外我假设片断验证失败，可能是因为第一个 block ，即 block 0(有故障或损坏)
然后我应该重新排队 block 0 和 block 1(这是有效的顺便说一句，也是第 1 部分的一部分)再次重新传输。

现在突然间， block 和 block 的分布变得有点复杂，就像我想象的那样。我希望有一个更简单的解决方案。

任何想法

Answer 1

Will use the more distinct term 'chunk' instead of the ambiguous 'block'.

洪流被分成几部分。

一 block 被分成 block 。

从一 block 上切下一 block 。

洪流在创建时被分成几部分。与 请求 消息，一个片段又被下载的 BitTorrent 客户端进一步分成 block 。
客户端如何从一 block 中切出 block 并不重要，只要没有单个 block 大于 16 KB(16384 字节)。
分割一 block 最简单和最合理的方法是尽可能少地进行分割，将其分割成 16 KB 的 block ，并在必要时让最后一 block 更小。

The Request message format: <len=0013><id=6><Piece_index><Chunk_offset><Chunk_length>

• <Piece_index > integer specifying the zero-based piece index
• <Chunk_offset> integer specifying the zero-based byte offset within the piece
• <Chunk_length> integer specifying the requested number of bytes

请求 block 时:

整个 block 必须在 Piece_index 指定的 block 内 ,
即Chunk_offset + Chunk_length必须小于或等于该特定件的大小*。

Chunk_length不能大于 16 KB(16384 字节)并且必须至少为 1 字节

获得请求的对等体必须具有 Piece_index 指定的片段

如果其中任何一个条件不满足，接收请求的对等方将关闭连接。

* 除了最后一个是 'piece length' 之外的所有部分在信息字典中定义。
最后一 block 的大小可以计算为: size_last_piece = size_of_torrent - (number_of_pieces - 1) * 'piece length'