>> It sounds like you may be suggesting that I'd have a more abstract >> message queue in between the clients and workers and perhaps use some >> detail of the application layer to dispatch the messages instead of >> having a "direct" link between client and service provider? >> >> (I realize I'm probably overloading/misusing some terms so feel free >> to correct me if it helps get on the same page) > > No, you are right. We were just speaking about different scenarios. > > You were speaking of the use case where client connect directly to the > services while I had the case where there's a node (shared queue) in the > middle.
Does either model offer any significant advantages over the other in terms of using 0MQ as a RPC transport layer? I have seen RPC implemented over direct socket connections and also implemented in terms of a shared queue on top of an enterprise-y MQ product. I see 0MQ as falling somewhere in between those two paradigms I'd be interested to hear thoughts on pros/cons of either model. Would a general purpose RPC service container be advised to support both? _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev