[zeromq-dev] Point-to-Point Client/Server Request/Response
charrington at datascaler.com
Mon Apr 27 19:49:41 CEST 2009
This routing functionality is very useful to us. What is the timeframe for
On Mon, Apr 27, 2009 at 12:49 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Hi Alex,
> > Studying the excellent design documentation. Wanted to get an
> > understandng how a conventional point-to-point conversation would be
> > mapped in 0MQ solution space with practicality left aside. Assuming a
> > number n of private (firewalled) clients each sending 'requests' to a
> > single public server and waiting for their appropriate 'responses', we
> > would have:
> > 1. Server with Global Queue Q-REQ
> > 2. Each Client would create a Local Exchange E-REQ
> > 3. Each Client would bind their E-REQ to Q-REQ to send their request.
> > It is the next steps on how the server will handle the respones to the
> > each of the clients that is not so clear. Would we have:-
> > 4. Server creates an instance of a Global Exchange E-RESi...n for each
> > client
> > 5. Each Client would create a Local Queue Q-RES
> > 6. Each Client would bind their Q-RES to their corresponding E-RESx to
> > recieve their response.
> > Obviously, it feels like there should be a more elegant solution. Or is
> > it a case of trying to fit a square peg in a round hole.
> You are right. That's the only solution at the moment. (0MQ was designed
> primarily for pub/sub model so req/rep is, well... ugly.
> However, the solution is being implemented right now. Actually, there's
> a "routing" branch in SVN that implements it, however, it has
> experimental status at the moment. For more info have a look here:
> Once the routing is in place, req/rep is easy and efficient:
> 1. Server declares a global queue and global exchange
> 2. Each client has it's own unique identity (a string)
> 3. Client binds it's local queue to the global exchange and its local
> exchange to the global queue.
> 4. Client subscribes for messages tagged by it's identity.
> 5. Client sends requests tagged by it's identity.
> 6. Server reads requests and generates replies; it tags replies by the
> identity taken from the request.
> 7. Client reads the replies (only the correct ones are delivered because
> of the subscription.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev