When networking a computer system, protocols play an important role. An example is the Internet protocol, which was published in a first specification in 1981, and is the indispensable basis for the smooth sending and receiving of data packets. But what is behind the RFC standard? And how does the Internet protocol actually work?
In IT, messages constantly need to be sent from one service to another. This has to happen in a controlled way, otherwise the messages block each other, a queue forms and processes can’t be executed optimally. For applications to be able to communicate with each other without problems, it makes sense to use a kind of middle man, a service that takes over distributing the messages. We call this a message broker. Here we introduce one of the most well-known: RabbitMQ.
What is RabbitMQ?
RabbitMQ is based on the idea of the advanced message queuing protocol (AMQP). The main advantage of AMQP is that sender and recipient don’t need to understand the same coding language. The message broker has since moved away from AMQP somewhat and, with the aid of plug-ins, is also compatible with message protocols like STOMP and MQTT, but the idea remains the same: There is a queue between the producer and the consumer of a message. The messages are stored temporarily in this queue.
In this context, the term ‘message’ is used very broadly. Messages could be actual messages including text, or instructions to other programs. Any form of information transfer can take place through RabbitMQ or other message brokers.
The advantage of RabbitMQ is that the producer of the message doesn’t need to take charge of sending the message. The message broker takes the message away, giving the producer the chance to start on a different task. The sender doesn’t need to wait for the recipient to have received the message. In this process, the message sits in a queue, and can then be picked up by the consumer. By this time, though, the sender is already working on something new. This, then, is an asynchronous process, as sender and recipient don’t need to work around each other.
The process with RabbitMQ
There are four stations in conveying messages:
- Producer: creates messages
- Exchange: forwards messages
- Queue: stores messages
- Consumer: processes the message
The producer releases a message, but doesn’t send this directly to the consumer, instead handing it over to the exchange. This position is responsible for distributing messages to different queues, from which the consumers can help themselves to the messages. Both the exchange and the queues are part of RabbitMQ, and are administered by the software. Routing keys are used to make sure that messages reach the correct recipient. The sender provides the message with a routing key that works like an address. Based on the key, the exchange recognises how the message is to be routed.
A binding exists as a link between the exchange and the queue. Through this, each individual queue is connected to the exchange. Binding also defines the criteria for forwarding a message. There are four main ways of distributing messages.
Direct exchange is a direct connection between sender and recipient. The producer equips the message with a routing key that corresponds to a routing key in the queue. This means that only one queue is possible, which in turn generally serves only one consumer.
This exchange type extends the concept of direct exchange. Instead of just one criterion (routing key = binding key), several queues can be called upon. This works using placeholders. In this way, certain queues and binding keys can be accepted, while others remain excluded.
Fan-out exchange is a broadcast. A message is distributed to all available queues without any sorting, and the routing key is ignored.
With header exchanges, too, the system ignores the routing key. Instead, the header of the message plays an important role, as it’s here that the exchange finds the attributes to direct the message to the correct queues. In this respect, a header exchange works analogously to topic exchanges, because in this case several queues, but not all, can be called upon.
Consumers, that is the receiving software, register to certain queues and take the messages from these. For this reason, only one consumer is envisaged per queue. If several consumers take messages out of a queue, the correct distribution can’t be guaranteed. Optionally, the user can decide for each message whether the recipient needs to confirm receipt or whether this isn’t necessary.
RabbitMQ in use
RabbitMQ is an open-source server written in the coding language Erlang, and can be downloaded from the official website for Linux, BSD, Unix, Windows and macOS. Plug-ins are also recommended to ease the message broker’s workload and expand its range of functions. The most important here would be the management plug-in, which is part of the standard installation but has to be activated. It allows users to manage RabbitMQ via a GUI, keep an overview of messages in queues, and view statistics.
The plug-in Shovel, which makes it possible to connect two broker entities together, could also be useful. This makes sense, for example, to better distribute the load. It can also shift sensitive data or extensive quantities of data to a completely different network for security reasons.
The communication is carried out via TCP, which is why RabbitMQ requires ports. These may not be closed, or blocked by other applications. RabbitMQ’s documentation includes a list of all ports used.
The main advantage of RabbitMQ is its slim structure. The message broker can be set up quickly, and can be used in many situations. In larger-scale scenarios, however, developers and admins prefer to use Apache Kafka.