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 > [email protected] > [email protected] > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
