[zeromq-dev] Advanced request/reply broker pattern

Zachary Turner divisortheory at gmail.com
Mon Aug 22 18:52:29 CEST 2011

Hi all,

I'm trying to model a situation that's a little similar to the Request-Reply
Broker in the zmq guide, but not quite.  I'm having trouble figuring out how
to model the scenario.

The general premise is this: I have N identical clients and M identical
servers.  Typically N is quite large and M is quite small.  Each of the M
servers should maintain a connection to *every other server*, and each of
the N clients should maintain a connection to exactly 1 server.  Any of
these clients may, at any given time, need to send a message to any one of
the other N clients.  It will do this by sending the message to the one
server it is connected to, and that server S will then use some algorithm to
determine if the destination client is connected to S, just send it
directly.  If not, the algorithm determines which server S' the client *is*
connected to, and then forwards the message to S'.

The point of this topology is that I get a best case scenario of 2 hops per
transmission, and a worst case scenario of 3 hops per transmission.
 However, I'm having difficulty modeling it.

Some additional requirements:
- Whether or not a reply is necessary depends on the specific message in
question.  This means that not all messages warrant replies and as such I
feel like ZMQ_REQ and ZMQ_REP sockets are inappropriate.
- I would like to avoid using explicit identities.

I have a situation working right now where every client has 1 ZMQ_XREP
socket and every server has 2 ZMQ_XREP sockets (1 for clients and 1 for
servers), and this appears to get the job done, but I can't figure out how
to do this without using explicit identities.  If my server decides that it
needs to send a message to a specific client (or forward it to a specific
server), how can it tell ZMQ which one to send it to without explicit
identities?  It also seems odd that every single socket in my design is a
ZMQ_XREP socket, and it makes me wonder if there's a better solution.

I've also been told that explicit identities will be deprecated in a
subsequent release anyway and so eventually I will have to move off of this

Can anyone advise?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110822/11a6aaf1/attachment.htm>

More information about the zeromq-dev mailing list