Trivial archetypes
ZeroMQ “ sockets ” are similar to a socket-oriented device, but upon closer inspection, this intelligent library is more likely to add a Formal Communication Pattern (which uses a real socket), which has a multi-level design to internally address details such as internal elastic buffering, internal 1: N Fair Queuing / Poll, ioThread internal load balancing, to name just a few.
Probably, on these internal intelligent subsystems, as well as on elementary formal communication patterns, named as closely as possible, similar to human-like behavioral (one) - PUB licenses + (others) - SUB -scribe - ZeroMQ builds a "ground floor" much more powerful messaging schemes.
As a good helper, instead of saying PUB socket, you can assume that SUB , XPUB or DEALER more likely entity-with- "behavior" , sitting on one end of a telephone line that has some hard habits that he can use during a phone call.
Thus, some entities can talk to each other, since PUB can talk to one or more SUB (s) - not knowing how many / if there are () related to its, well, strong> any of its telephone lines (yes, PUB can have many outgoing phone lines), as well as for detailed information on the available ZeroMQ available classes of transport, which the PUB can “set for incoming calls” or otherwise (yes, even the PUB can “pick up one of its phone lines” and dial (. connect () aside) the selected counterparty of SUB or XSUB ! Cool ... (Yes, as many functions of ZeroMQ are developed ny)) - all this in parallel.
SUB may, at its discretion, decide and subscribe to the filter what to hear and what not to hear from the incoming telephone line. Naturally, some others are simply not equipped in their pre-wire behavior to be able to call each other everywhere and consciously enter into a viable conversation, but they can speak with him a "friendly" (behaviorally compatible) counterparty (a PAIR , as an example, has the only and only chance to go and call + talk with another PAIR -buddy).
For a deeper understanding of these building blocks, including the XPUB / XSUB , why they should have distributed the simple PUB / SUB primitive, the best way to recommend this is to read Pieter Hintjens's book, “Code Connected, Volume 1” (available for download in pdf format) )
(IMHO is a must-have book, not only about the clever properties of ZeroMQ per-se, but about a shift in thinking and other inspiring thoughts)
ROUTER / DEALER and DEALER / ROUTER
These formal communication patterns are well illustrated in Fig. 37 and discussed in this book. It is worth reading it than just getting a few words here.
A ROUTER to DEALER example (a 1-to-N ), when one server speaks asynchronously with several workers, you can turn upside down to get a very useful N-to-1 , where different clients communicate with the same server and do it asynchronously. So the specific use case is determined by your design need.
XPUB / XSUB use case
As soon as you connect to the " interacting " connection methods between the primitive ZeroMQ elements, the XPUB / XSUB proxy device "serves another additional service than just a proxy to .bind() and .connect() to. It also" interprets "the contents of the message ( checking the incoming zmq.SUBSCRIBE -s and passing them to the real- PUB -lisher side through its own XSUB proxy), reading the XPUB socket XPUB . This is the main use case for XSUB and XPUB
Challenging the ZMQ arsenal element as such is not the goal. It is rather a set of LEGO building blocks for developing distributed message templates for specific projects that work together according to a more complex need - self-healing after a single node failure, performance scalability, adaptive reconfiguration, and many others.
Only one image, fig. 60: 
Integrated Systems
A typical real-world application should go much further than just reusing the elementary primitives PAIR / PAIR , XREQ / XREP , ... where they fit your higher level accordingly, and at which you add a behavior strategy that uses these archetypes lower level under your global design control.
In order to streamline the code, it is worth spending time on the book first, and not vice versa.
It will save you from aha! after a few seconds.