[zeromq-dev] Clever uses of XREP/XREQ
Matt Weinstein
matt_weinstein at yahoo.com
Thu Jul 22 03:20:21 CEST 2010
This is quite nice.
On Jul 21, 2010, at 3:20 PM, Brian Granger wrote:
> [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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list