ZeroMQ, or ØMQ, or even ZMQ, is a tool aimed at asynchronous communication between servers. It offers several approaches for communicating via socket using unicast or multicast.
Its implementation consists of a very lightweight messaging system, specially designed for high throughput/low latency scenarios. Furthermore, ØMQ is completely decoupled and can implement any messaging protocol, unlike other technologies such as RabbitMQ, which natively implements AMQP.
However, when using ØMQ, the handling of advanced scenarios such as routing, load balancing, message queuing and message persistence in case of failures or restarts must be configured in the project itself.
Ultimately, ØMQ is lighter as it has far fewer native implementations. But it also offers total control over the flow of your application, making it interesting for cases of extreme complexity and also cases where minimal latency will make a big difference.
In ØMQ, messages are divided into multiple parts, where each part is called a frame. This will be used to add "headers" to each frame. zmq itself will either deliver all the frames or none of them.
No ØMQ, the existing connection types (socket) are:
-
inproc - using the
zmq_inproc()function to transport messages via memory directly between threads that share a single ØMQ context. It can be used in Exclusive-pair patterns, as shown in the documentation itself. -
ipc - uses
zmq_ipc()to transport messages between local processes using a system-dependent IPC mechanism. It can be used to implement a Pipeline service as shown in the documentation. Currently it only works on UNIX servers. -
tcp - uses
zmq_tcp()to establish an asynchronous remote connection between servers. It is widely used in Request-Reply, where data traffic will not be done with HTTP. Instead, use the ØMQ pattern itself with a specified length and message. The image below illustrates how data is passed through socket.
-
pgm - uses
zmq_pgm()to implement a multicast strategy, where data frames are sent via a set of IP addresses. It can be used in Pub-sub patterns as shown in the documentation. -
epgm - can be activated through
zmq_epgm(), it is similar to normal pgm, but here the data frames travel via UDP. It can be used in Pub-sub patterns as shown in the documentation.
It is a communication protocol where the client makes a request to the server, waits for a response while the server processes the request, and finally returns a response to the client. To implement this use case, ØMQ offers packaging that separates the message payload from an envelope.
The envelope will contain the return address for responses. This is how even ØMQ does not store state, it can implement request-response applications. The image below illustrates a request received by the server, where frame 1 is the address of the client that made the request. You can capture this address and send a response to it.
