[zeromq-dev] Clever uses of XREP/XREQ

[Brian Granger]

[I sent this the other day, but I think it may have gotten lost]

Hi,

We are using XREQ/XREP a lot these days and one of our developers came
across some interesting uses of them.  I wanted to see if these uses
were official supported, see if others were doing these types of
things and point out these interesting cases to others.

1. XREQ/XREP are designed primarily for request/reply style messaging
with multiple requesters or multiple repliers.  In this type of
setting sockets tend to do strict SRSRSRSRSR.... sequences.  But,
because XREQ sockets allow multiple outstanding requests, in reality,
an XREQ/XREP pair can do any combination of messages, just like pair
sockets.  The XREQ doesn't even have to start the interaction.

In one of our applications, we use this capability for a replier to
issue multiple replies for a single request.

2. The usual approach is to use an XREQ to issue a request that is
load balanced to XREP repliers.  In this case the XREQ socket binds
and the XREP socket connects.  BUT, given (1), you can invert this to
get interesting routing possibilities.  Here is how it works.  Create
an XREP that binds:

c = zmq.Context()
s = c.socket(zmq.XREP)
s.bind(...)

This socket will be used to send *routed* requests.  Then in your
repliers, create XREQ sockets that connect:

c = zmq.Context()
s = c.socket(zmq.XREQ)
s.connect()

Now, the XREP socket can make requests to particular XREQ sockets by
doing a multipart message with the identify of the XREQ socket passed
as the first part.  Notice that in this usage case, the XREQ/XREP
roles are swapped compared to normal.  We are using this in one of our
applications where we want load balancing, but in a manual manner that
allow our application to choose which client gets to handle which
message.  The beauty is that the XREQ clients can send a presence
message with its identity to the XREP socket when it connects.  From
then on, the XREP will know the identity that it can use to route
messages to that client in the future.

We think these are pretty clever uses of these socket types.  Some questions:

* Is this supported behavior (please say yes) or might this go away in
the future?
* Are there any issues to be aware of that we might run into in this
configuration in a high load context?
* Anyone else using these or other sockets in creative ways?

Cheers,

Brian
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com