Google Protocol Buffers - 固定大小的缓冲区?
使用 Google Protocol Buffers,我可以为我编码的所有消息设置最大大小吗?
如果我知道我编码的内容永远不会大于 X 字节,那么 Google Protobuffs 总是会生成大小为 Y 的缓冲区,如果我给它较小的数据量,请将其填充到大小 Y?
Using Google Protocol Buffers, can I set a maximum size for all messages I encode?
if I know that what I encode is never larger than X bytes, then Google Protobuffs would always produce a buffer of size Y, and if I give it a smaller amount of data, pad it to size Y?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
协议缓冲区的有线格式不会让这变得微不足道;我不知道有什么办法可以做到这一点,但一种选择是将其序列化到带有您自己的长度标头的缓冲区中,并根据需要填充额外的数据。
您需要添加一个长度前缀,因为默认情况下不会添加它,否则它将在缓冲区末尾读取垃圾。即使尾随 0 也是不合法的(它将寻找字段编号)。
我无法评论 C++ 或 Jon 的 C# 版本,但对于我的 C# 版本 (protobuf-net),您应该能够执行类似的操作(未经测试):
如果还使用,这应该可以反序列化
DeserializeWithLengthPrefix
。回复问题(评论);
SerializeWithLengthPrefix
是一个 protobuf-net 特定的方法; C++ 版本中可能有一些东西,但它非常简单。从头开始实现这个的最简单方法是:,显然:
在 protobuf-net 中稍微复杂一点,因为它提供了更多选项(如何对 int 进行编码,以及是否将其包装起来,以便整个thing 仍然可以被视为 100% 值 protobuf 流 - 特别是我怀疑我刚刚描述了如果我要求
SerializeWithLengthPrefix
使用固定的行为 -宽度编码和“字段 0”)。The wire format for protocol buffers wouldn't make this trivial; I'm not aware of something to do this, but one option would be to serialize it into a buffer with your own length header and pad with extra data as needed.
You need to add a length prefix because this is not added by default, and otherwise it would be reading garbage at the end of your buffer. Even trailing 0s would not be legal (it would be looking for a field number).
I can't comment on the C++ or Jon's C# version, but for my C# version (protobuf-net), you should be able to do something like (untested):
This should deserialize fine if also using
DeserializeWithLengthPrefix
.Re the questions (comments);
SerializeWithLengthPrefix
is a protobuf-net-specific method; there may be something in the C++ version, but it is pretty simple. The easiest way to implement this from scratch is:in reverse, obviously:
It is a little bit more complex in protobuf-net, as it offers a few more options (how the int should be encoded, and whether or not to wrap this so that the entire thing can still be treated as a 100% value protobuf stream - in particular I suspect I've just described the behaviour if I asked
SerializeWithLengthPrefix
to use fixed-width encoding and "field 0").