[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
