I am trying to determine the exact behaviour and potential limitations of the so-called 'Extended Pub-Sub architecture' from the ØMQ guide.
XPUB and XSUB are described:
We need XPUB and XSUB sockets because ZeroMQ does subscription forwarding from subscribers to publishers. XSUB and XPUB are exactly like SUB and PUB except they expose subscriptions as special messages. The proxy has to forward these subscription messages from subscriber side to publisher side, by reading them from the XSUB socket and writing them to the XPUB socket. This is the main use case for XSUB and XPUB.
I've set up a the XSUB and XPUB sockets as the front-end and back-end of a proxy, and have another pair of PAIR sockets wired into the capture port. This allows me to observe the messages being passed through the proxy.
In my architecture each node is both a PUB and a SUB. Essentially I'm hoping this XPUB/XSUB proxy will provide a shared bus, with topic-prefix subscriptions.
After a SUB node connects, it must subscribe with a (potentially empty) topic. This causes a one-frame message to be transmitted through the proxy. Assuming my topic is {0xff 0xFF}, the message is:
{0x01 0xFF 0xFF}
The leading 0x01 indicates a subscription, followed by the topic bytes. A similar message with a 0x00 instead of a 0x01 represents an unsubscribe.
What I am concerned about is where exactly the subscription information is kept in this architecture.
According to the guide:
From ZeroMQ v3.x, filtering happens at the publisher side when using a connected protocol (
tcp://oripc://).
If filtering is indeed performed on the publisher side, then is it a problem if a SUB subscribes before a PUB comes online? Will the PUB be informed of pre-existing subscriptions, perhaps from XSUB?
My system will have nodes with dynamic lifetimes. Will this be an issue, and are there any other issues I should be aware of?