Messaging Confusion: Pub/Sub vs Multicast vs Fan Out

Question

I've been evaluating messaging technologies for my company but I've become very confused by the conceptual differences between a few terms:

Pub/Sub vs Multicast vs Fan Out I am working with the following definitions:

• Pub/Sub has publishers delivering a separate copy of each message to each subscriber which means that the opportunity to guarantee delivery exists
• Fan Out has a single queue pushing to all listening clients.
• Multicast just spams out data and if someone is listening then fine, if not, it doesn't matter. No possibility to guarantee a client definitely gets a message.

Are these definitions right? Or is Pub/Sub the pattern and multicast, direct, fanout etc. ways to acheive the pattern?

I'm trying to work the out-of-the-box RabbitMQ definitions into our architecture but I'm just going around in circles at the moment trying to write the specs for our app.

Please could someone advise me whether I am right?

Gynandrous

Answer 1

I'm confused by your choice of three terms to compare. Within RabbitMQ, Fanout and Direct are exchange types. Pub-Sub is a generic messaging pattern but not an exchange type. And you didn't even mention the 3rd and most important Exchange type, namely Topic. In fact, you can implement Fanout behavior on a Topic exchange just by declaring multiple queues with the same binding key. And you can define Direct behavior on a Topic exchange by declaring a Queue with * as the wildcard binding key.

Pub-Sub is generally understood as a pattern in which an application publishes messages which are consumed by several subscribers.

With RabbitMQ/AMQP it is important to remember that messages are always published to exchanges. Then exchanges route to queues. And queues deliver messages to subscribers. The behavior of the exchange is important. In Topic exchanges, the routing key from the publisher is matched up to the binding key from the subscriber in order to make the routing decision. Binding keys can have wildcard patterns which further influences the routing decision. More complicated routing can be done based on the content of message headers using a headers exchange type

RabbitMQ doesn't guarantee delivery of messages but you can get guaranteed delivery by choosing the right options(delivery mode = 2 for persistent msgs), and declaring exchanges and queues in advance of running your application so that messages are not discarded.

Mordvin

this is the kind of answer I was hoping for. Didn't know that topics could simulate the other exchange types so thats useful. – Gynandrous

Note: Using a Topic exchange to simulate either fanout or direct is slightly slower than using either of the specific exchange types. It's the classic performance / flexibility trade off. – Grivation

It's not true. You cant simulate fanout with task queues. It's because after first consuming the story is ended. – Hurter

@iddqd: I don:t understand what you are saying. There is no such thing as task queues in AMQP. You simulate a fanout exchange with a topic exchange. Your consumers declare different queue names with the same binding key and the messages to this topic exchange which have a routing key matching the binding key, get fanned out (copied) to each one of the queues. Consuming messages happens AFTER the message is routed to the queue. See this question for more info #5254057 – Mordvin

Sorry, my mistake i fount it answer during searching AMQP+celery. – Hurter

Answer 2

Your definitions are pretty much correct. Note that guaranteed delivery is not limited to pub/sub only, and it can be done with fanout too. And yes, pub/sub is a very basic description which can be realized with specific methods like fanout, direct and so on.

There are more messaging patterns which you might find useful. Have a look at Enterprise Integration Patterns for more details.

Bioecology

Answer 3

From an electronic exchange point of view the term “Multicast” means “the message is placed on the wire once” and all client applications that are listening can read the message off the “wire”. Any solution that makes N copies of the message for the N clients is not multicast. In addition to examining the source code one can also use a “sniffer” to determine how many copies of the message is sent over the wire from the messaging system. And yes, multicast messages are a form the UDP protocol message. See: http://en.wikipedia.org/wiki/Multicast for a general description. About ten years ago, we used the messaging system from TIBCO that supported multicast. See: https://docs.tibco.com/pub/ems_openvms_c_client/8.0.0-june-2013/docs/html/tib_ems_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_ems_users_guide&file=EMS.5.091.htm

Quadruple