There seems to be a bit confusion on subject. Let's de-mystify the PUB-SUB
Case 1) a SUB who "does not provide a filter"
This is btw a default initial state right after an instantiation
aSub_signallingChannelEND = aCentralCONTEXT.socket( zmq.SUB )
In this initial state, there is no valid subscription (pre-)set, naturally, as the Context()
is a rational process ( not a Norn ) and as such it cannot a-priori assume any such universally valid subscription-key ( and it would be pretty Orwellish if it could, wouldn't it? ) so as to indoctrinate a SUB
-instance to have it "breathed-in" since it's birth.
In original ZeroMQ v2.x ( note, that this was documented not to be valid for the newest version o the ZeroMQ library ) this state however does not mean the SUB
side does not get physically receive any messages. The v2.x subscription filtering was performed ( be it due to performance motivated decisions or not ) on SUB
-side, so the wire-level detection of "un-authorised" messages was still possible
Case 2) a SUB who "did provide a super-set of all filters"
Short version:
In principle, PUB
-side per-se has no controls to discriminate any SUB
-side decision about what to subscribe-to and what to unsubscribe-from.
How to get it work in a given manner?
As PUB-SUB
messaging pattern is defined this way, you have to help yourself with either a smart-layered setup for authentication needs you have beyond the PUB-SUB
pattern, or one can use other means for added authentication based protection ( for example a tailor-made right/key for authentication-based selective-ability for code/decode content-use to highlight some of the possible approaches ).