0

I am using pub/Sub Socket and currently the server subscribe byte[0] (all topics) while client subscribe byte[16] - a specific header as topic

However, I cannot stop client to subscribe byte[0] which can receive all other messages.

My application is a like a app game which has one single server using ZMQ as connection and many clients have a ZMQ sockets to talk with server.

What pattern or socket I should use in this case?

Thanks

MobileDev
  • 178
  • 3
  • 14
  • Have you successfully implemented a solution to stop clients from subscribing all topics? Can you briefly tell what was your final solution? – Michał Fronczyk Apr 25 '15 at 02:02

1 Answers1

0

" ... cannot stop client to subscribe byte[0] which can receive all other messages."

Stopping a "subscribe to all" mode of the SUB client

For the ZMQ PUB/SUB Formal Communication Pattern archetype, the SUB client has to submit it's subscription request ( via zmq_setsockopt() ).

PUB-side ( a Game Server ) has got no option to do that from it's side.

There is no-subscription state right on a creation of a new SUB socket, thus an absolutely restrictive filter, thas no message pass through. ( For furhter details on methods for SUBSCRIBE / UNSUBSCRIBE ref. below )

ZeroMQ specification details setting for this:

int zmq_setsockopt (       void   *socket,
                           int     option_name,
                     const void   *option_value,
                           size_t  option_len
                     );

Caution: only ZMQ_SUBSCRIBE
              ZMQ_UNSUBSCRIBE
              ZMQ_LINGER
         take effect immediately,
         other options are active only for subsequent socket bind/connects.

ZMQ_SUBSCRIBE: Establish message filter

The ZMQ_SUBSCRIBE option shall establish a new message filter on a ZMQ_SUB socket. Newly created ZMQ_SUB sockets shall filter out all incoming messages, therefore you should call this option to establish an initial message filter.

An empty option_value of length zero shall subscribe to all incoming messages.

A non-empty option_value shall subscribe to all messages beginning with the specified prefix.

Multiple filters may be attached to a single ZMQ_SUB socket, in which case a message shall be accepted if it matches at least one filter.

ZMQ_UNSUBSCRIBE: Remove message filter

The ZMQ_UNSUBSCRIBE option shall remove an existing message filter on a ZMQ_SUB socket. The filter specified must match an existing filter previously established with the ZMQ_SUBSCRIBE option. If the socket has several instances of the same filter attached the ZMQ_UNSUBSCRIBE option shall remove only one instance, leaving the rest in place and functional.

How to enforce an ad-hoc, server-dictated, ZMQ_SUBSCRIBE restrictions?

This is possible via extending the messaging layer and adding a control-mode socket, that will carry server-initiated settings for the client ZMQ_SUB messages filtering.

Upon receiving a new, the server-dictated, ZMQ_SUBSCRIBE/ZMQ_UNSUBSCRIBE setting, the ZMQ_SUB client side code will simply handle that request and add zmq_setsockopt() accordingly.

FSA-driven grammars for this approach are rich of further possibilites, so will allow any Game Server / Game Community to smoothly go this way.

What pattern or socket I should use?

ZeroMQ is rather a library of LEGO-style elements to get assembled into a bigger picture.

Expecting such a smart library to have a one-size-fits-all ninja-element is on a closer look an oxymoron.

So, to avoid a "Never-ending-story" of adding "although this ... and also that ..."

  1. Review all requirements and & list features for the end-to-end scaleable solution,

  2. Design a messaging concept & validate it to meet all the listed requirements & cover all features in [1]

  3. Implement [2]

  4. Test [3] & correct it for meeting 1:1 the end-to-end specification [1]

  5. Enjoy it. You have done it end-to-end right.

user3666197
  • 1
  • 6
  • 50
  • 92
  • Thanks for the info. Although the SUB client has to submit it's restrictive subscription request, I cannot enforce it to subscribe by filter. Although my application can do, my concern is if any hacker/attack can easily remove the message filter by themselves and subscribe all messages. – MobileDev Sep 06 '14 at 05:44
  • @Billy Let's address the issue step by step. [a] **Yes**, SUB-client has to submit (any) subscription request. [b] **Yes**, you can enforce the content of the subscription request, by an application-specific/hardware-id/et al default value first & than reading it from server control-channel as described above. [c] **Yes**, there is always a way to "hack" & those who indeed care may implement adequately higher levels of authetication / transaction-state / transaction-content protection, up to a MIL-STD-level robust solution. – user3666197 Sep 06 '14 at 05:55
  • I change to Dealer-Router-Dealer model. So that clients work as dealer and server has a router socket and dealer to handle the request. However, the latency for server to receive client's message become 100x more. I wonder if it is because there is something built for each dealer message. And if pub-sub is by-nature much faster than router-dealer socket. Thank you. – MobileDev Sep 08 '14 at 09:42
  • @Billy **What** is your **Design** [2] **target** for **n** -`clients` and **what** is your **Design** [2] **target** for maximum **acceptable** `latency[ms]` so as to speak in hard facts? – user3666197 Sep 08 '14 at 10:51
  • previous pub-sub is within 10 ms (without network latency), right now is 1 sec. Our acceptable latency is within 10 ms anyway. There must be something wrong for the dealer-router-dealer pattern... target client is over thousand per second. – MobileDev Sep 08 '14 at 10:55
  • Very updated.. I change the number of worker dealer to more than 1 (previous was 1), the speed is much faster... within 50ms now. I don't know why because I am testing by one client only currently... – MobileDev Sep 08 '14 at 11:03
  • @Billy As far as my past experience goes, there are **several order of magnitudes less frequent a case** when there is *"something wrong"* with the ZeroMQ pattern **compared to** the cases of inappropriate archetype use or mis-understood logic of the Scaleable Formal Communication Pattern archetype use in some more complex distributed messaging system or a Design flaw. – user3666197 Sep 08 '14 at 11:11