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.