Library – Inter-process communication – ZMQ
ZeroMQ (also known as ØMQ, 0MQ, or ZMQ) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It’s fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. It has a score of language APIs and runs on most operating systems. ZeroMQ is from iMatix and is LGPLv3 open source.
Messaging patterns are network oriented architectural pattern that describes the flow of communication between interconnecting systems.
Each pattern in ØMQ defines the constraints on the network topology – What systems can connect to each other and the flow of communication between them. These patterns are designed to scale.
(Exclusive) Pair – PAIR sockets
- PAIR is not a general-purpose socket but is intended for specific use cases where the two peers are architecturally stable. This usually limits PAIR to use within a single process, for inter-thread communication.
- The communication is bidirectional – The server listens on a port and the client(s) connect to it.
- The other peer receives the fully message or no parts of it whatsoever.
- Each of them can send any number of messages to each other.
C++1234Client --> Server: REQUEST_1Client --> Server: REQUEST_2Client <-- Server: RESPONSE_1Client <-- Server: RESPONSE_2
Request / Reply – REQ / RESP sockets
- Client sends a request and the server replies to it.
- The difference between this type and the Pair is that:
- The server will block on recv until it receives a request
- The client will block on send (cannot send more messages) until he receives a reply back from previous request.
C++12345Client --> Server: REQUEST_1Client <-- Server: RESPONSE_1Client --> Server: REQUEST_2Client <-- Server: RESPONSE_2
- Not ok:
C++12Client --> Server: REQUEST_1Client --> Server: REQUEST_2 (cannot send this message until RESPONSE_1 is received)
- Further reading:
Publish / Subscribe – PUB / SUB sockets
- The client can subscribe (register) to a message broadcast and will receive an update from the publisher (server) when a new message.
- The usual example is when you register to a newsletter to receive updates from them.
- Let’s say the server can notify users for EVENT_1 and EVENT_2.
C++123456789101112131415161718Client_1 --> Server: Connect!Server received message: Client_1 connected.Client_2 --> Server: Connect!Server received message: Client_2 connected.Client_1 --> Server: Register EVENT_1Server added Client_1 as subscriber to EVENT_1.Client_2 --> Server: Register EVENT_1, EVENT_2Server added Client_2 as subscriber to EVENT_1, EVENT_2.Server broadcast: (EVENT_1,data)Client_1 received message: (EVENT_1,data)Client_2 received message: (EVENT_1,data)Server broadcast: (EVENT_2,data)Client_2 received message: (EVENT_2,data)
- Further reading:
Pipeline (Producer/Consumer method) – PUSH / PULL sockets
- Push and Pull sockets let you distribute messages to multiple workers, arranged in a pipeline.
- This is a parallel task distribution and collection pattern.
- Further reading:
Types of transport for communication:
- In-Process (INPROC): Local (in-process) communication transport.
- Inter-Process (IPC): Local (inter-process) communication transport.
- TCP: Unicast communication transport using TCP.
- PGM: Multicast communication transport using PGM.
Further reading / learning: