Search code examples
socketszeromqpublish-subscribeinproc

ZeroMQ mixed PUB/SUB DEALER/ROUTER pattern

I need to do the following:

  • multiple clients connecting to the SAME remote port
  • each of the clients open 2 different sockets, one is a PUB/SUB, the other is a ROUTER/DEALER ( the server can occasionally send back to client heartbeats, different server related information ).

I am completely lost whether it can be done in ZeroMQ or not. Obviously if I can use 2 remote ports, that is not an issue, but I fail to understand if my setup can be achieved with some kind of envelope usage in ZeroMQ. Can it be done? Thanks,

Update:

To clarify what I wish to achieve.

  • Multiple clients can communicate with the server
  • Clients operate on request-response basis mostly(on one socket)
  • Clients create a session socket, which means that whenever this
    type of socket is created, a separate worker thread needs to be created and from that time on the client communicates with this worker thread with regards to requests processing, e.g. server thread must not block the connection of other clients when dealing with the request of one client
  • However clients can receive occasional messages from the worker thread with regards to heartbeats of the worker.

Update2:

Actually I could sort it out. What I did:

  • identify clients obviously, so ROUTER/DEALER is used, e.g. clients are indeed dealers, hence async processing is provided
  • clients send messages to the one and only local port, where the router sits
  • router peeks into messages (kinda the lazy pirate example), checks whether a new client comes in; if yes it offloads to a separate thread, and connects the separate thread with an internal "inproc:" socket
  • router obviously polls for the frontend and all connected clients' backends and sends messages back and forth.

What bugs me is that it is an overkill if I compare this with a "regular" socket solution, where I could have connected the client with the worker thread DIRECTLY (e.g. worker thread could recv from the socket opened by the client directly), hence I could spare the routing completely.
What am I missing?

Solution

  • There was a discussion on the ZeroMQ mailing list recently about multiplexing multiple services on one TCP socket. The proposed solutions is essentially what you implemented.

    The discussion also mentions Malamute with its brokers which essentially provides a framework based on ZeroMQ which also provides the functionality you need. I haven't had the time to look into it myself, but it looks promising.