CODEWITHSUNDEEP
zeromqpublish-subscribe
stix
stix

Reputation: 1146

Best approach for multiple envelopes in ZeroMQ pub/sub pattern?

I'm trying to design a pub/sub architecture with ZeroMQ, and I want to make maximum use of ZMQ's internal filtering for subscribers.

What is the best way to handle multiple message envelopes in ZMQ so that the receiving subscriber only sees messages that match all of the envelopes it's interested in?

As an example hierarchy, let's say I have a UniverseID, a SessionID, and a MessageTypeID, and I want to find all of the MessageTypeIDs of a given type for a given session and universe, like this:

UniverseID (Subscriber Key, Example = 42)
    SessionID (Subscriber Key, Example = 4)
        MessageTypeID (Subscriber Key, Example = 2)
           Message (Actual Message)

Is there a way in ZMQ of filtering the messages like a "layered filter" with multiple frames or is the best way to build a single key within a single envelope frame (i.e. as "UniverseID.SessionID.MessageTypeID" or in our example "42.4.2")?

The end goal is to have zero filtering done by the subscriber outside of ZMQ, so that if I call zmq_recv on my socket, I only see messages which match all three subscriber keys and don't have to manually check if I'm interested in the message before doing anything with it.

Upvotes: 3

Views: 1932

Answers (1)

Timothy Shields
Timothy Shields

Reputation: 79441

Is there a way in ZMQ of filtering the messages like a "layered filter" with multiple frames or is the best way to build a single key within a single envelope frame (i.e. as "UniverseID.SessionID.MessageTypeID" or in our example "42.4.2")?

This is the way to go (with one minor modification).

  • If you want all messages, subscribe with no prefix.
  • If you want all messages with UniverseID A, subscribe with the prefix A.
  • If you want all messages with UniverseID A and SessionID B, subscribe with the prefix A.B.
  • If you want all messages with UniverseID A, SessionID B, and MessageTypeID C, subscribe with the prefix A.B.C.

Note the addition of the final . that I've added to the end of the key. That's just so you don't have to treat the case when all the IDs are specified as a special case.

Upvotes: 3

Related Questions