纳米消息(NNG)& FlatBuffers是否适合该项目? [英] NanoMsg (NNG) & FlatBuffers the correct fit for this project?
问题描述
大声疾呼，如果有更好的事情，我们应该考虑:
Shout out if there is something better we should consider:
我正在寻找一种非常快速，简单的方法来获取多个程序(例如5个)，每个程序都在私有OpenStack云上的单独节点上运行以相互通信.
I am looking for a very quick and simple way to get several programs (e.g. 5) - each running on separate nodes on a private OpenStack cloud to talk to each other.
- 数据包将是简短的C ++结构(少于100个字节)
- 交通流量会很轻(可能少于100/秒)
- 延迟确实不是问题. (朋友之间的间隔时间是几毫秒?)-我们有很多循环和记忆力
- 消息应以发布/订阅客户端/服务器范式完成
- 库应该是C ++友好的.但是可以在Windows和Linux上使用
- 我们稍后可能需要其他语言绑定
- 我们宁愿不丢失消息
这是我的第一个主意.但是，如果您还有其他选择.喊出来.
Here is the first idea I have. But if you have something else to offer. Yell out.
UDP套接字层的友好包装:
- NanoMSG(因为它是nanoMsg的活动项目，所以为NNG) https://github.com/nanomsg/nng
用于C ++结构数据的编码器/解码器:
- FlatBuffers https://google.github.io/flatbuffers/
推荐答案
对于序列化，几乎所有具有正确语言绑定的内容都可以使用. Google协议缓冲区与语言无关，可以使用许多绑定.唯一要避免的是源代码中内置的序列化(例如Boost的序列化为/was)，因为那样的话，您就不能轻易将其移植到另一种语言.
For serialisation, almost anything with the right language bindings will do. Google Protocol Buffers are language-agnostic, lots of bindings available. The only thing to avoid is serialisation that is built into your source code (like Boost's serialisation is / was), because then you can't readily port that to another language.
对于消息传输，ZeroMQ，NanoMsg是不错的选择.但是，我认为这实际上归结为
For message transport, ZeroMQ, NanoMsg are good choices. However, I think it really comes down to
- 您不想丢失消息有多严重，
- 确切地说，您所说的丢失的消息"是什么意思.
关于ZeroMQ(和NanoMsg)的问题是(AFAIK)，没有真正的方法可以知道发生故障时消息的命运.例如，在ZeroMQ中，如果您发送一条消息而接收方恰好正在工作并且已连接，则该消息将通过连接进行传输.现在，发送端认为作业已完成，消息已传递.但是，除非并且直到接收端实际调用zmq_recv()并完全处理它给出的内容，否则如果接收端进程崩溃，断电等原因，消息仍然可能丢失.这是因为直到消耗完为止消息存储在ZeroMQ运行线程内部的RAM中(在相应的Context() -instance的控制域内).
The thing about ZeroMQ (and NanoMsg) is (AFAIK) there is no real way of knowing the fate of a message when a fault occurs. For instance, in ZeroMQ, if you send a message and the recipient just happens to be working and connected, the message gets transferred over the connection. The sending end now thinks that the job is done, the message has been delivered. However, unless and until the receiving end actually calls zmq_recv() and fully processes what it gets given, the message can still get lost if the receiving end process crashes, of there is a power failure, etc. This is because until it is consumed the message is stored in RAM inside the ZeroMQ run thread ( inside the respective Context()-instance's domain of control ).
您可以通过以某种方式向其他方向发送确认消息来解决此问题，例如超时等.但是这种情况开始变得很怪异，最好使用RabbitMQ之类的东西.
You can account for this by having some sort of ack message heading back the other way, timeouts, etc. But that starts getting fiddly, and you'd be better off with something like RabbitMQ.
这篇关于纳米消息(NNG)& FlatBuffers是否适合该项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
