问题
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 nodes on a private OpenStack cloud to talk to each other.
- Packets will be short C++ structs (less than 100 bytes)
- Traffic will be light (probably less than 100/second)
- Latency is really not an issue. (what is a few ms between friends?) - we have lots of cycles and memory
- Messages should be done as pub/sub client/server paradigm
- Library should be C++ friendly. But work both on Windows and Linux
- We might need additional language bindings later on
- We would prefer not to lose messages
Here is the first idea I have. But if you have something else to offer. Yell out.
Friendly Wrapper for UDP socket layer:
- NanoMSG (NNG since it is the active project of nanoMsg) https://github.com/nanomsg/nng
Encoder/Decoder for C++ struct data:
- FlatBuffers https://google.github.io/flatbuffers/
回答1:
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
- How badly you don't want to lose messages,
- 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.
回答2:
With an utmost respect to Margaret HAMILTON's work for Apollo Programme.
Yell out.
Dear Dr.,
there are many features, that will become important for a professional decision, that were not mentioned in the shopping-list above.
If the Apollo AGC example could help here, the better.
The package under seek :
- ought keep your code in control of relative processing-priorities,
- ought let one increase / decrease / map IO-threads resources-pool usage, per channel,
- ought let one setup the L3+ transport ToS-prioritisation tagging,
- ought let one modify O/S configured L3 / L2 stack implementation resources,
- ought permit non-blocking controls from application programme side, without risks of any deadlocks,
- ought provide wide portfolio of transport-classes covering { inproc: | ipc: | tipc: | tcp: | udp: | vmci:| pgm: | epgm: } as needed to get employed in a mix
if all that sounds important for your further efforts in Draper Lab, the ZeroMQ will smoothly fit in ( if some latency / performance figures might need boosted on steroids as being more important than the mature mix above, may also enjoy to review Martin Sustrik's another kid, younger than his ZeroMQ - the nanomsg tools ).
Anyway, if you indeed have (cit.) "... lots of cycles and memory ...", just let me in, I have lots of TFLOP-s to process, if you permit, in the spare time :o)
Nota Bene:
Given the recent comments, let me add a remark on using Naval Research Laboratory published NACK-Oriented Reliable Multicast (NORM) norm:// transport-class, that may help your pure PUB/SUB-design intentions, for which it seems it can fix the desire to "prefer not to lose messages" that is otherwise not taken care off, according to the Zen-of-Zero, which leaves all such operations onto the user-side application code and distributed-system behaviour.
来源：https://stackoverflow.com/questions/50862992/nanomsg-nng-flatbuffers-the-correct-fit-for-this-project