NanoMsg（NNG）＆amp; Flat是否适合这个项目？

Question

如果我们应该考虑更好的事情，请大声喊出：

我正在寻找一种非常快速简单的方法来获取多个程序（例如5个） - 每个程序都运行在私有OpenStack云上的不同节点上，以便相互通信。

• 数据包将是短C ++结构（小于100字节）
• 交通将很轻（可能少于100 /秒）
• 延迟确实不是问题。 （朋友之间的几分钟几点？） - 我们有很多周期和记忆
• 消息应该以pub / sub client / server范例
完成
• 库应该是C ++友好的。但是在Windows和Linux上工作
• 我们稍后可能需要其他语言绑定
• 我们不想丢失消息

这是我的第一个想法。但如果你还有别的东西可以提供。大喊大叫。

UDP套接字层的友好包装：

• NanoMSG（NNG，因为它是nanoMsg的活跃项目）https://github.com/nanomsg/nng

C ++结构数据的编码器/解码器：

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

Answer 1

对于序列化，几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers与语言无关，可以使用大量绑定。唯一要避免的是源代码中内置的序列化（比如Boost的序列化是/是），因为那样你就不能轻易地将它移植到另一种语言中。

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

1. 你不想丢失信息有多糟糕，
2. 首先，“丢失的信息”正是您的意思。
关于ZeroMQ（和NanoMsg）的事情是（AFAIK），当发生故障时，没有真正了解消息命运的方法。例如，在ZeroMQ中，如果您发送消息并且收件人恰好正在工作并连接，则消息将通过连接传输。发送端现在认为作业已完成，消息已经发送。但是，除非并且直到接收端实际调用zmq_recv()并完全处理它给出的内容，否则如果接收端进程崩溃，出现电源故障等，则消息仍然会丢失。这是因为直到它消耗的消息存储在ZeroMQ运行线程内的RAM中（在相应的Context() - 实例的控制域内）。

你可以通过让某种ack消息向前反转，超时等来解释这个问题。但是这种情况开始变得很繁琐，你最好还是选择像RabbitMQ这样的东西。

Answer 2

非常尊重玛格丽特·哈米尔顿为阿波罗计划所做的工作。

  

大喊大叫。

亲爱的博士，
有许多功能，对于专业决策而言将变得非常重要，而这些功能在上面的购物清单中没有提及。

如果Apollo AGC示例在这里有所帮助，那就更好了。

寻求的包裹：

• 应该让您的代码控制相对处理优先级，
• 应该让一个增加/减少/映射IO线程资源池使用，每个通道，
• 应该让人们设置L3 +传输ToS优先级标记，
• 应该修改O / S配置的L3 / L2堆栈实现资源，
• 应该允许来自应用程序端的非阻塞控件，没有任何死锁的风险，
• 应提供涵盖{inproc：|的广泛的传输类组合ipc：|提示：| tcp：| udp：| VMCI：| pgm：| epgm：}根据需要在混合中使用

如果所有这些对于您在Draper实验室的进一步努力而言非常重要，那么ZeroMQ将顺利适应（如果某些延迟/性能数据可能需要增强类固醇，因为它比上述成熟混合更重要，也可以享受审查Martin Sustrik的另一个孩子，比他的ZeroMQ更年轻 - nanomsg工具。

无论如何，如果你确实有（cit。）“ ......很多周期和记忆... ”，请让我进去，我有很多如果您允许，TFLOP将在业余时间:o)

进行处理

Nota Bene：

鉴于最近的评论，让我补充说明使用海军研究实验室发布的面向NACK的可靠多播（NORM） norm:// 传输类，这可能有助于您的纯{{ 1}} - 设计意图，它似乎可以修复希望“不要丢失消息 ”，否则不会被照顾，根据禅宗-of-Zero，将所有此类操作留在用户端应用程序代码和 distributed-system 行为。