c++ - NanoMsg(NNG)和FlatBuffers是否适合该项目？

喊出是否有更好的东西，我们应该考虑:

我正在寻找一种获取多个程序(例如5个)的快速，简单的方法-每个程序都在私有(private)OpenStack云上的单独节点上运行以相互通信。

数据包将是简短的C++结构(少于100个字节)

流量不大(可能少于100 /秒)

延迟确实不是问题。 ( friend 之间几毫秒？)-我们有很多循环和内存

消息应作为发布/订阅客户端/服务器范例

完成

库应该是C++友好的。但是在Windows和Linux上均可使用

我们稍后可能需要在

上使用其他语言绑定(bind)

我们希望不要丢失消息

这是我的第一个想法。但是，如果您还有其他选择。喊出来。

UDP套接字层的友好包装:

NanoMSG(由于它是nanoMsg的 Activity 项目，因此为NNG)https://github.com/nanomsg/nng

用于C++结构数据的编码器/解码器:

FlatBuffers https://google.github.io/flatbuffers/

最佳答案

对于序列化，几乎所有具有正确语言绑定(bind)的东西都可以。 Google Protocol Buffer 与语言无关，可以使用许多绑定(bind)。唯一要避免的是源代码中内置的序列化(例如Boost的序列化是/ was)，因为那样的话，您就不能轻易将其移植到另一种语言。

对于消息传输，ZeroMQ，NanoMsg是不错的选择。但是，我认为这实际上归结为

不想丢失消息有多严重

首先，您确切是“丢失消息”的意思。

有关ZeroMQ(和NanoMsg)的问题是(AFAIK)，没有真正的方法可以知道发生故障时消息的命运。例如，在ZeroMQ中，如果您发送一条消息而接收者恰好正在工作并且已连接，则该消息将通过连接进行传输。现在发送端认为作业已完成，消息已传递。但是，除非并且直到接收端实际调用zmq_recv()并完全处理给出的内容，否则如果接收端进程崩溃，断电等原因，消息仍然可能丢失。这是因为直到消息被消耗为止存储在ZeroMQ运行线程内的RAM中(在相应的Context() -instance的控制域内)。

您可以通过以其他方式返回一些确认消息(例如超时等)来解决此问题。但是这种情况开始变得很奇怪，并且最好使用RabbitMQ之类的方法。