谷歌协议和大型二进制blob

Question

我正在构建一个软件来远程控制连接到另一台PC的无线电硬件。

我计划使用ZeroMQ进行传输，并使用类似于RPC的请求-回复，其上有表示操作的不同消息。

虽然我的大多数消息只是一些控制和状态信息，但应该可以选择设置要传输的数据blob或请求要接收的数据blob。这些数据blob通常在5-10MB的范围内，但也应该可以使用最大100MB的较大blob。

对于消息格式，我发现google协议缓冲区非常有吸引力，因为我可以在传输链路上定义一种消息类型，该类型具有所有命令和响应的可选元素。然而，protobuf FAQ指出，如此大的消息将对性能产生负面影响。

所以问题是，这到底有多糟糕？预计会有什么负面影响？我真的不想把整个通信都建立在protobuf上，结果却发现它不起作用。

Answer 1

我没有时间为您做这件事，但我会浏览原型源代码。更好的是，继续使用大型bytes字段编写您的代码，从源代码构建原型，并在调试器中逐步完成它以查看发送和接收大型blob时会发生什么。

根据经验，我可以告诉您，大型重复消息字段没有效率，除非它们具有[packed=true]属性，但这仅适用于基本类型。

我的直觉是，大的字节字段将是有效的，但这是完全没有根据的。

您还可以为您的大型blob绕过Protbuf：

message BlobInfo {
    required fixed64 size;
    ...
}

message MainFormat {
    ...
    optional BlobInfo blob;
}

然后您的解析代码如下所示：

...
if (message.has_blob()) {
    uint64_t size = msg.blob()->size();
    zmqsock.recv(blob_buffer, size);
}

Answer 2

坦率地说，这与其说是html" target="_blank">性能本身，不如说是库的设计方式不适合处理大型消息。例如，您必须一次解析一条消息，然后一次序列化它。因此，如果您有一条包含100MB blob的消息，那么您无法读取消息的任何部分，除非您读取整个100MB并在解析时阻止调用线程。还有一个问题是，100MB blob将被分配为一个巨大的扁平字节数组。在64位系统上，这可能很好，但在32位系统上，可能存在地址空间碎片问题。最后，有一个2GB的硬消息大小限制。

如果你对这些问题没有意见，那么你几乎可以这么做。您必须手动覆盖邮件大小限制，出于安全目的，该限制默认为64MB。为此，您需要手动构造一个CodedInputStream，并在解析消息之前对其调用SetTotalBytesLimit（）。

但就我个人而言，我建议尝试设计您的系统，以便可以将大Blob拆分为小块。