protobuf中流消息实现的比较 [英] Comparison of streaming message implementations in protobuf

问题描述

在对多个相同类型的消息进行编码的情况下，这些流实现中的每一个的权衡、优点和缺点是什么?

What are the trade-offs, advantages and disadvantages of each of these streaming implementations where multiple messages of the same type are encoded?

它们有什么不同吗?我想要实现的是将一个盒子向量存储到一个 protobuf 中.

Are they any different at all ? What I want achieve is to store a vector of box'es, into a protobuf.

实施例 1:

package foo;

message Boxes
{ 
  message Box 
  { required int32 w = 1;
    required int32 h = 2;
  }

  repeated Box boxes = 1; 
}

实现 2:

package foo;

message Box 
{ required int32 w = 1;
  required int32 h = 2;
}

message Boxes 
{ repeated Box boxes = 1; 
}

Impl 3 :将多个这些消息流式传输到同一个文件中.

Impl 3 : Stream multiple of these messages into the same file.

package foo;

message Box 
{ required int32 w = 1;
  required int32 h = 2;
}

推荐答案

1 &2 只更改声明类型的位置/方式.作品本身将是相同的.

1 & 2 only change where / how the types are declared. The work itself will be identical.

3 更有趣:在 Box 之后，你不能只是在 Box 之后Box 流式传输Box，因为protobuf 中的根对象未终止(以允许 concat === 合并).如果你只写Boxes，当你反序列化时，你将只有一个Box，最后一个w和h 写的.您需要添加一个长度前缀；你可以任意地这样做，但是:如果你碰巧选择了varint"-编码长度，你接近repeated给你的 - 除了repeated 还包括在每个varint"长度之前的字段头(字段 1，类型 2 - 所以二进制 1010 = 十进制 10).

3 is more interesting: you can't just stream Box after Box after Box, because the root object in protobuf is not terminated (to allow concat === merge). If you only write Boxes, when you deserialize you will have exactly one Box with the last w and h that were written. You need to add a length-prefix; you could do that arbitrarily, but: if you happen to choose to "varint"-encode the length, you're close to what the repeated gives you - except the repeated also includes a field-header (field 1, type 2 - so binary 1010 = decimal 10) before each "varint" length.

如果我是你，为了简单起见，我只会使用 repeated.您选择 1/2 中的哪一个取决于个人选择.

If I were you, I'd just use the repeated for simplicity. Which of 1 / 2 you choose would depend on personal choice.

这篇关于protobuf中流消息实现的比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！