Is there a way to reverse the bind on zmq pub/sub?

Question

I have server code on one box that needs to listen in on status coming from another box with about 10 chips with linux embedded in them. The 10 chips have their own ip addresses and each will send basically health status to the server which could (possibly) do something with it.

I would like the server just to passively listen and not have to send a response. So, this looks like a job for zmq's pub/sub. Where, each of the 10 chips have their own publication and the server would subscribe to each.

However, the server would need to know the well known address that each chip bound their publication to. But, in the field, these chips can be swapped or replace with a different ip address.

Instead, it's safer to have the chips know the server code's ip adddress.

What I would like a pub/sub where the receiver is the well known address. Or, a request/response pattern where the clients (the chips) send a messages to the server (the requests), but neither the server nor the chips need to send/receive a response.

Now, currently, there are two servers on the separate box. So, if possible I'd like a solution for one server and multiple servers.

Is this possible in zmq? And what pattern would that be?

thanks.

Answer 1

Yes, you can do this exactly the way you'd expect to do so. Just bind on your subscriber, then connect to that subscriber with your publishers. ZMQ doesn't designate which end should be the "server", or more reliable end, and which should be the "client", or more transient end, specifically for this reason, and this is an excellent reason to switch up the normal paradigm.

Edit to address the new clarification--

It should work fine with multiple servers. In general it would work like the following (the order of operations in this case is just to ensure no messages get lost, which is possible if the PUB socket starts sending messages before the SUB is ready):

1. Spin up server 1. Create SUB socket and bind on address:port.
2. Spin up server 2. Create SUB socket and bind on address:port.
3. Spin up a chip. That chip will create a PUB socket and connect on [server 1] address:port and connect on [server 2] address:port.
4. Repeat step (3) for the other nine chips.

Answer 2

Dual .SUB model

Oh yes, each .PUB-lishing entity may have numerous .SUB-s listening, so having two <serverNode>-s meets the .PUB/.SUB-primitive Formal Communication Pattern ( one speaks - many listen )

As given above, each of your <serverNode> binds

.bind( aFixServer{A|B}_ipAddress_portNumber )

so as allow each .PUB-lishing <chipNode> to

.connect( anAprioriKnownServer{A|B}_bindingNode_ipAddress_portNumber )

And both <serverNode{A|B}> than .SUB-s to receive any messages from them.

Multi-Server model

As seen above, the {A|B} grammar is freely extensible to {A|B|C|D|...} so the principal messaging model will stand for any reasonable multi-server extension

Q.E.D.