Rat*_*lle 4 bittorrent bit-fields
我对bittorrent中的位字段消息有点困惑。我已经注意到下面问题形式的混乱。
握手序列完成后立即发送的位字段
我假设这是强制性的，即握手后必须遵循位字段消息。正确的？
位域消息只能在握手序列完成后、发送任何其他消息之前立即发送
假设我清楚地阅读了此消息，尽管它是可选消息。对等方仍然可以在任何消息（如请求、choke、uncoke 等）之前广播位字段消息。正确的 ？
如果我是正确的，位字段代表状态，即对等方是否拥有给定的块。
假设我的位域是[1,1,1,1,1,1,1,1,1,1 ..]. 我确定对等点丢失了第 10 块，如果位字段看起来像这样，[1,1,0,1,1,1,1,1,1,1 ..]则对等点丢失了第 3 块。那么第一个字节的高位对应的片索引0意味着什么。
末尾的备用位设置为零
这是什么意思 ？我的意思是，如果末尾有一个位为 0，并不意味着同行将其作为缺失的部分。为什么使用备用位。
我对此的预感是，位字段可以更轻松地找到合适的对等点，以了解对等点可用的信息，但我对此是否正确？
@Encombe
这是我的位字段有效负载的样子
\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF \xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF \xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF \xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF \xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF \xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFE
我假设这是强制性的，即握手后必须遵循位字段消息。正确的？
不，位域消息是可选的，但如果客户端发送它，它必须是握手后的第一条消息。
此外，在任何一方开始发送任何类型的常规消息（包括位域消息）之前，两个对等方都必须发送完整的握手（即握手序列已完成）。
假设我清楚地阅读了此消息，尽管它是可选消息。对等方仍然可以在任何消息（如请求、choke、uncoke 等）之前广播位字段消息。正确的 ？
是的，见上文。如果客户端在其他任何地方发送位字段消息，则必须关闭连接。
假设我的位域是 [1,1,1,1,1,1,1,1,1,1 ..]。我确定对方缺少第 10 件物品
不。我不清楚你的数字是位（0b1111111111）还是字节（0x01010101010101010101）。
如果是位（0b11111111）：表示有 0 到 9 块
如果是字节 ( 0x01010101010101010101): 表示有 7, 15, 23, 31, 39, 47, 55, 63, 71 和 79
如果位字段看起来像这样 [1,1,0,1,1,1,1,1,1,1 ..]，则对等点缺少第三部分。
不，片段的索引为零。0b1101111111: 表示缺少第 2 块。
那么第一个字节的高位对应的片索引0意味着什么。
这意味着索引为 0 的片段由最左边的位表示。（bigendian 中的最高有效位。）
. eight bits = one byte
. 0b10000000 = 0x80
. ^高位设置意味着客户端拥有第 0 块
. 0b00000001 = 0x01
. ^低位设置意味着客户端有第 7 块
为什么使用备用位
如果激流中的片段数量不能被八整除；位域的最后一个字节中将会有一些位超出，但不代表任何片段。这些位必须设置为零。
位字段的大小（以字节为单位）可以这样计算：
size_bitfield = math.ceil( number_of_pieces / 8 )
备用位的数量为：
spare_bits = 8 * size_bitfield - number_of_pieces
位域的用途是什么
目的是告诉客户端有哪些片段，以便其他对等方知道它可以请求哪些片段。