CODEWITHSUNDEEP
zeromq
petke
petke

Reputation: 1435

Howto find out all the subscribed to filters in a PUB server?

I have a PUB server. How can it tell what filters are subscribed to, so the server knows what data it has to create?

The server doesn't need to create data once no SUB clients are interested in.

Say the set of possible filters is huge ( or infinite ), but subscribers at any given time are just subscribed to a few of them.

Example: Say SUB clients are only subscribed to a weather feed data for a few area codes in New York and Paris. Then the PUB server shouldn't have to create weather data for every other area code in every other city in the world, just to throw it all away again.

How do you find out all the subscribed to filters in a PUB server?

If there is no easy way, how do I solve this in another way?

Upvotes: 5

Views: 101

Answers (1)

petke
petke

Reputation: 1435

I'll answer my own question here in case its of use to anyone else.

The requirements where:

  1. The client should be able to ask the server what ids (topics) are available for subscription.

  2. The client should chooses the id's it is interested in and tell the server about it.

  3. The server should created data for all subscribed too id's and send that data to clients.

  4. The client and server should not block/hang if either one goes away.

Implementation:

Step 1. Is two way traffic, and is done with REQ/REP sockets.

Step 2. Is one way traffic from one client to one server, and is done by PUSH/PULL sockets.

Step 3. Is one way traffic from one server to many clients, and is done by PUB/SUB sockets.

Step 4. The receives can block either the server or client if the other one is not there. Therefore I followed the "lazy pirate pattern" of checking if there is anything to receive in the queue, before I try and receive. (If there is nothing in the queue I'll check again on the next loop of the program etc).

Step 4+. Clients can die without unsubscribing, and the server wont know about it, It will continue to publish data for those ids. A solution is for the client to resends the subscription information (with a timestamp) every so often to the server. This works as a heartbeat for the ids the client has subscribed too. If the client dies without unsubscribing, the server notices that some subscription ids have not been refreshed in a while (the timestamp). The server removes those ids.

This solution seems to work fine. It was a lot of low level work though. It would be nice if zeromq was a bit higher level, and had some common and reliable architectures/frameworks ready to use out of the box.

Upvotes: 1

Related Questions