Hi Steven, > Basically this is a TIBCO Rendezvous Distributed Queue, a quick overview: > > The RVDQ appears as one endpoint to communication and requires no > special action on the client. The client can communicate via reliable > or confirmed delivery to the queue. > > Each member of the RVDQ partakes in a fault tolerant group, one member > gets elected as the scheduler. It is the schedulers job to assign tasks > to workers. > > Communication between the scheduler and workers is always via confirmed > delivery.
Yes, I am aware TIBCO does it this way. However, it seems to be an order of magnitude more complex compared to what we have now in 0MQ. Thus, if anyone feels strong about request/reply on top of multicast, feel free to discuss how to implement it in 0MQ. In the meantime, I am going to focus in missing unicast request/reply features. (Currently I am working on multi-hop req/rep.) Martin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
