Understanding advanced ZeroMQ socket types

I've read the 0MQ guide, and I understand the basic socket types: PUSH/PULL, REQ/REP, and PUB/SUB.

I'm very confused though about ROUTER/DEALER and the X- sockets (e.g., XSUB/XPUB, XREQ/XREP).

What are the use cases for these socket types?

Solution 1:

Trivial Archetypes

ZeroMQ "sockets" are sounding alike a socket-oriented device, however on a closer look this smart library rather adds a Formal Communication Pattern ( which btw. uses a true socket ) that has a layered design to internally address details like internal elastic-buffering, internal 1:N Fair-Queue-Sending / Polling, internal ioThread load-balancing, to name just a few.

Atop on these internal smart subsystems, aka the elementary Formal Communication Patterns -- named as close as possible to resemble a human-alike behaviour -like- (one)-PUB-lishes + (others)-SUB-scribe -- ZeroMQ builds a "ground floor" of much more powerful messaging schemes.

As a good helper, instead of saying a PUB-socket, one may opt to imagine a SUB, XPUB or DEALER to be rather an entity-with-"behaviour", sitting on one end of the phone-line, who has some hard-wired habits, that it can use during a phone-call.

So, some entities can speak one to the other, alike PUB can speak to one or many SUB(s) - without knowing how many / if any is (are) connected to his, well, to any of his phone-lines ( yes, PUB can have many outgoing phone-lines -- plus for details check the ZeroMQ transport Classes available, that PUB can "expose for incoming calls" or otherwise deploy --( Oh yes, even PUB can "pick up one of his phone-lines" and dial ( .connect() towards ) a selected SUB or XSUB counterparty! Cool... (Yes, as many ZeroMQ features designed-in) )-- all of that in parallel.

SUB can upon its discretion decide and subscribe to filter, what to hear and what not to hear from the incoming phone-line. Naturally, some others are simply not equipped within their pre-wired behaviour to be able to universally phone each other and get meaningfully get into a viable conversation, but can talk to it's "friendly" (behavioral-compatible) counterparty ( a PAIR, as an example, has a one and the only chance to go and ring + speak to another PAIR-buddy ).

For deeper understanding of these building blocks, incl, the XPUB/XSUB motivation, why they had to extend the plain PUB/SUB primitive, the best way one can recommend is to read Pieter Hintjens' book "Code Connected, Volume 1" ( downloadable as pdf).

( IMHO a must-read book, not just about the smart properties of ZeroMQ per-se, but about the shift in mindset and other inspiring thoughts ).

ROUTER/DEALER & DEALER/ROUTER

These Formal Communication Patterns are well illustrated in Fig.37 and discussed around, in the said book. Worth reading it, than just getting a few words here.

A ROUTER to DEALER example ( a 1-to-N use case ) where one server talks asynchronously to multiple workers can be turned "upside down" to get a very useful N-to-1 architecture where various clients talk to a single server, and do this asynchronously. So exact use-case is given by your design need.

XPUB / XSUB use case

Once getting to the "inter-mediated" mode of connections among the ZeroMQ primitive elements, the XPUB/XSUB proxy "device" serves one more add-on service than just being a proxy to .bind() & .connect() to. It also "interpretes" the message-content ( checking incoming zmq.SUBSCRIBE-s & transfers 'em towards the real-PUB-lisher side via the proxy own XSUB ) by reading the XPUB socket side.This is the main use case for XSUB and XPUB

Mastering the ZMQ arsenal element-by-element as such is not the goal per-se. It is rather a LEGO-style kit of building blocks for designing project-specific distributed messaging patterns, that co-operate according to a more complex need -- self-healing after a single node failure, performance-scaleability, adaptive-reconfiguration and many others.

Just one picture, Fig.60:

Complex Systems

Typical real-world application has to go much farther than just to re-use the elementary PAIR/PAIR, XREQ/XREP, ... primitives, where these appropriately fit into your higher-level design needs, and atop of which you add a behaviour strategy, that uses these lower-level archetypes under your global design control.

For getting code arranged, worth spending a time with the book first, not vice versa.

This will save you a lot of Aha! moments later.