NanoMsg (NNG) & FlatBuffers the correct fit for this project?

后端 未结 2 1827
臣服心动
臣服心动 2021-01-03 15:36

Shout out if there is something better we should consider:

I am looking for a very quick and simple way to get several programs (e.g. 5) - each running on separate n

2条回答
  •  清酒与你
    2021-01-03 16:19

    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.

    For message transport, ZeroMQ, NanoMsg are good choices. However, I think it really comes down to

    1. How badly you don't want to lose messages,
    2. Exactly what you mean by "lost message" in the first place.

    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 ).

    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.

提交回复
热议问题