c++ - 有哪些对二进制打包结构消息进行版本控制的好方法？

Question

我有一个应用程序可以多播某些打包的 POD 结构和一个在其他二进制文件中运行的监听器服务。监听器服务知道结构是什么样子，所以当它收到它们时，它会将其转换回用 reinterpret_cast 击中的结构并执行回调。

问题在于，如果发布了二进制文件并且需要将新信息添加到结构中，则必须重建这些二进制文件，否则它们将被reinterpret_cast - ing 和滥用信息。在生产环境中，这可能是一个问题，因为生产环境并不总是具有这种灵 active 。

有人告诉我的一件事是，解决这个问题的方法是引入新的消息样式，并同时发送它们。随着时间的推移，应用程序最终将切换到新型二进制消息直到有人可以停止发送旧的。我想知道是否有更好的选择。

例如，如果约定只将新字段添加到打包结构的末尾，那么旧的监听二进制文件可能仍然能够访问这些新字段(如果他们愿意)，而那些使用旧的构建的二进制文件信息可能仍然能够访问顶部部分。因此，例如，如果发件人正在多播:

struct foo {
    int  a;
    char b[2];
} __attribute__ ((packed));

然后在接收器端构建了几个二进制文件，这些二进制文件通过网络获取 const char* msg 消息并执行此操作:

foo* fooPtr = reinterpret_cast<foo*>(msg); 
registeredGuy->callback(fooPtr);

现在，如果我们决定在发件人端推出额外的信息，老听众可能会同意我们像这样将其固定在底部:

struct foo {
    int  a;
    char b[2];
    char newStuff[17];
    int  k;
} __attribute ((packed));

老接收者应该仍然能够成功转换和访问他们的旧信息，而新接收者可以访问新内容。这是真的？是否有更好的解决方案不会影响速度(性能非常关键)

Answer 1

发送本质上相同的消息的两个版本不是一个好主意。特别是对于性能关键系统。您最终花费的时间至少是实际发送时间的两倍。您最终还会广播两倍多的信息，因此您的网络可能会饱和。

只要消息有效负载本身就存在版本控制消息有效负载的问题。我的想法是解决问题的最佳方法是完全避免它。

关键是了解客户将如何接收和处理入站数据。通常，客户端将监听线路上的 UDP 帧，吸收它，并将该帧作为消息处理。理想情况下，您的 UDP 帧小于体系结构的 MTU(例如 1500 字节)，因此消息不会在传输过程中被切碎。它们可能会乱序到达，但这是一个完全不同的问题。

客户知道 UDP 帧有多大，因为他们将它从网络上拉下来。他们还知道他们将处理的消息有多大，因为它只是 sizeof(MessageType)。他们唯一不知道的是帧大小和有效负载大小之间的差异。您可以通过在每封邮件中包含固定大小的 header 来告诉他们这一点。

标题看起来像这样:

struct MsgHeader
{
  size_t  msg_size_;
  int  msg_type_;
  char payload_[0];
};

实际的消息要么覆盖它，要么紧随其后(在 &payload_[0] 中)。

客户端现在读取 UDP 帧，从 header 中获取帧的大小，并将总字节数作为单个消息提取。从负载指针开始，客户端将入站数据转换为相关消息类型。如果单个消息中的数据多于客户端可理解的消息类型，则客户端会忽略它并将其丢弃在地板上。

当您更改消息时，您需要通过不移动任何现有字段的位置来确保向后二进制兼容性。在末尾添加新字段，相应地增加标题中的帧大小，Bob 就是你的叔叔。