protocol-buffers - 何时使用定值 protobuf 类型？或者在什么场景下？

Question

我想通过 TCP 传输序列化的 protobuf 消息，并且我尝试使用第一个字段来指示序列化消息的总长度。

我知道int32编码后会改变长度。所以，也许是 fixed32是个不错的选择。

但是在编码章节的最后，我发现即使我使用带有 field_num #1 的 fixed32 也不能依赖它。因为 Field Order说订单可能会改变。

我的问题是什么时候使用固定值类型？是否有任何示例场景？

Answer 1

"My question is when do I use fixed value types?"

当涉及到序列化值时，总是需要权衡取舍。如果我们看 Protobuf-documentation ，我们看到当涉及到 32 位整数时，我们有几个选择:

int32: Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead.

uint32: Uses variable-length encoding.

sint32: Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s.

fixed32: Always four bytes. More efficient than uint32 if values are often greater than 2^28.

sfixed32: Always four bytes.

int32是可变长度的数据类型。类型本身未指定的任何信息都需要以某种方式表达。要反序列化可变长度的数字，我们需要知道长度是多少。这也包含在序列化消息中，这需要额外的存储空间。可选的负号也是如此。因此，生成的消息可能会更小，但也可能会更大。
假设我们有很多 0 到 255 之间的整数要编码。将此信息作为两个字节发送(一个字节具有实际值，一个字节表示我们只有一个字节)比发送完整的 32 位(4 个字节)整数 [虚构值，实际实现可能有所不同]。另一方面，如果我们要序列化一个大值，那只能容纳 4 个字节，结果可能会更大(4 个字节和一个额外的字节表示该值是 4 个字节；总共 5 个字节)。在这种情况下，使用 fixed32 会更有效。 .我们只知道一个 fixed32是 4 个字节；我们不需要序列化 ​​ fixed32是一个 4 字节的数字。
如果我们看 fixed32它实际上提到权衡点大约是 2^28(对于无符号整数)。
因此，某些类型对于大值很好 [例如，在存储空间方面更有效]，有些适合小值，有些适合正/负值。这一切都取决于实际值代表什么。

"Are there any example scenarios?"

32 位哈希(即:CRC-32)、IPv4 地址/掩码。可预测的消息大小可能是相关的。