Message Bus versus Multicast

Question

I am working on an application that consists of several modules and requires that they exchange information with each other. Example: a publish / subscribe script when a module publishes some information (for example, a state variable) and modules that are interested in specific information. Or a request / response script, where the interested module explicitly requests information and receives a response.

I studied various implementations of the message bus, namely D-bus , ØMQ , RabbitMQ and QPID . > (the last two are based on AMQP). However, then someone pointed out that instead of trying to implement a complex and heavy message bus, why not just use multicast to solve the problem.

Without the experience to find out if multicast can really solve my problem and understand the pros and cons of the two solutions, I will ask experts to help me. I would really appreciate it.

Answer 1

Having experience with messaging and multicasting in a large, large work environment, and having talked with a few experienced network engineers about problems, I can say that you should avoid multicasting like the plague if you do not broadcast a lot nodes (hundreds).

If you intend to use multicast, you must understand that this is an untrusted protocol. Messages can go missing, they can be duplicated, and so on. You need to spend a lot of time getting the reliability protocol (retries, re-discovery, re-sending) on ​​top of the multicast to make it useful. There is a good joke about the army test of multicast team robotic tanks in which I try to find a link ... basically, when you send "turn right 90 degrees, turn right 90 degrees, fire" to the line of tanks and some of them only get one message with the right to turn, while the others get 3, this is a recipe for chaos.

Depending on the type of information you need to provide, there are several options.

If they use configuration information, look at something like Zookeeper. It is reliable, lightweight and easy to use. The most recent general status values ​​are always available and stored. With the message bus, you still need to have a resend protocol if your module skips the last configuration message if it is missing.

As for the message bus, they can be complicated. However, I would not put ZeroMQ in this category necessarily. It can emulate a message bus, but it is rather a point-to-point mechanism. I did not use it in production, but the research and prototypes that I did with it were very favorable.

Another option would be a distributed data network such as Oracle Coherence, GridGain, GigaSpaces, etc. Again, this is another application for installation and support, so your complexity is increasing, but there are many uses for a data grid.

Another option for MQ is HornetMQ. I did not use it (we use two commercial MQs inside the company, both Sonic and MQ Series), but I saw some favorable comparisons.

D-Bus seems to be optimized for communication on one machine, and it recommends looking at frequently asked questions elsewhere if you are doing peer-to-peer, cluster, or other similar things. Caveat: I never used D-Bus, so I basically tear down the information I just read.

Answer 2

Are you worried about dropping or losing packets or messages? Message buses can handle or mitigate these problems, while multicast will not be the default.