解析可变长度消息

发布于 2024-07-24 13:05:01 字数 770 浏览 13 评论 0 原文

我通过这个 spec 使用 Java 实现 BitTorrent 协议。在消息部分中，除其中 2 条消息外，所有消息都是固定长度的；对于其中一个，这是握手后唯一的可变消息，因此我可以检查其他消息，并在没有其他消息满足时假设它是一条消息。但对于下面的消息

位域：<位域> 
  
位域消息只能在握手序列完成后、发送任何其他消息之前立即发送。可选，如果客户端没有碎片则无需发送。

位域消息是可变长度的，其中X是位域的长度。有效负载是一个位字段，表示已成功下载的片段。第一个字节中的高位对应于片索引 0。清除的位表示丢失的片，设置的位表示有效且可用的片。末尾的备用位设置为零。

长度错误的位字段被视为错误。如果客户端收到大小不正确的位字段，或者该位字段设置了任何备用位，则应断开连接。

如果我不知道长度，我就无法想出解析它的方法；我该如何在字节流中找到 id ？

编辑：位域消息的有效负载是 torrent 文件中每个片段的 0 或 1，消息的长度将根据 torrent 内容的大小而变化。所以我不认为我可以假设碎片的数量总是适合 5 字节的数字。

原文

I am implementing the BitTorent protocol using Java via this spec. In the messages section all messages are fixed length except 2 of them; for one of them it's the only variable message after the handshake so I can check others and assume it's a piece message when no other messages met. But for the following message

bitfield: <len=0001+X><id=5><bitfield>
The bitfield message may only be sent immediately after the handshaking sequence is completed, and before any other messages are sent. It is optional, and need not be sent if a client has no pieces.

The bitfield message is variable length, where X is the length of the bitfield. The payload is a bitfield representing the pieces that have been successfully downloaded. The high bit in the first byte corresponds to piece index 0. Bits that are cleared indicated a missing piece, and set bits indicate a valid and available piece. Spare bits at the end are set to zero.

A bitfield of the wrong length is considered an error. Clients should drop the connection if they receive bitfields that are not of the correct size, or if the bitfield has any of the spare bits set.

I can't come up with a way to parse it if i do not know the length; how am I supposed to locate id in a stream of bytes?

Edit: In payload of the bitfield message is the 0's or 1's for each piece in the torrent file, length of the message will change depending on the size of the torrent content. So i don't think i can assume that the number of pieces will always fit in a 5 byte number.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

死开点丶别碍眼 2024-07-31 13:05:02

id 字段始终是消息的第 5 个字节，位于 len 字段的四个字节之后。您可以执行如下操作：

DataInputStream stream;

// ...

int    length  = stream.readInt();
byte   id      = stream.readByte();
byte[] payload = new byte[length - 1];

stream.readFully(payload);

实际上，这应该适用于任何消息，因为它们都具有相同的 len+id 标头。

编辑：“所以我认为我不能假设碎片的数量总是适合 5 字节的数字。”

四字节长度字段最多可以处理有效负载中的 2^32-1 字节，每个字节 8 位，可为您提供 34,359,738,360 个片段的空间。那应该够了！ :-)

The id field will always be the 5th byte of a message, after the four bytes for the len field. You can do something like the following:

DataInputStream stream;

// ...

int    length  = stream.readInt();
byte   id      = stream.readByte();
byte[] payload = new byte[length - 1];

stream.readFully(payload);

That should work for any message, actually, since they all have the same len+id header.

Edit: "So i don't think i can assume that the number of pieces will always fit in a 5 byte number."

A four-byte length field can handle up to 2^32-1 bytes in the payload, and with 8 bits per byte that gives you room for 34,359,738,360 pieces. That should be plenty! :-)

回复收藏 0 原文