2

According to the following discussion

Can ZMQ publish message to specific client by pub-sub socket?

there seems to be no possibility of preventing a subscriber from receiving all messages when he does not provide a filter.

Is it possible that a subscriber that provides no filter will not receive any messages? I.e., a subscriber does only receive messages, if he knows an exact filter (no wildcards, etc).

Rodrigo de Azevedo
  • 1,097
  • 9
  • 17
ceeroover
  • 2,475
  • 2
  • 11
  • 8

1 Answers1

1

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 ).

user3666197
  • 1
  • 6
  • 50
  • 92