I'm surprised that the docs aren't more clear about this detail. Honestly, the guide will teach you this but first you must read it. :)
The names imply the proper pairings. In what world does ROUTER / PULL make sense from a semantic standpoint? REQ is a subclass of DEALER. REP is a subclass of ROUTER. This is why we allow REQ / ROUTER and other pairings outside of the usual REQ / REP. The allowed pairings are: PUSH / PULL PUB / SUB PAIR / PAIR REQ / REP, REQ / ROUTER, DEALER / REP, DEALER / ROUTER, DEALER / DEALER and ROUTER / ROUTER cr On Nov 13, 2012, at 4:54 PM, Justin Karneges <[email protected]> wrote: > Then how do you justify, for example, the ability to mix REQ and ROUTER? Is > that just an exception to the rule? > > In my opinion, from a design point of view, zmq should either have very > strict > patterns (e.g. no more REQ+ROUTER), or it should allow mixing where it makes > sense (e.g. ROUTER+PULL). Doesn't this seem reasonable? Right now the allowed > mixing seems kind of arbitrary to me. > > On Wednesday, November 14, 2012 07:28:47 AM Pieter Hintjens wrote: >> There are reasons to not mix ROUTER and PULL, mainly that they are >> from different patterns, so if we decide to improve PUSH/PULL as a >> package, we would be unable, if people were mixing them with other >> patterns. >> >> As an example, see how we improved PUB/SUB to do pub-side filtering. >> >> DEALER does just the same as PUSH + PULL, so ROUTER/DEALER gives you >> what you want, and is better too, since you can do things like send >> heartbeats in both directions. >> >> -Pieter >> >> On Wed, Nov 14, 2012 at 4:02 AM, Justin Karneges <[email protected]> wrote: >>> Why not make it allowed in a future version? It doesn't seem any more >>> unusual than other mixings. >>> >>> On Tuesday, November 13, 2012 12:32:33 PM Chuck Remes wrote: >>>> No, do not do this. If it works at all right now, it will break in a >>>> future >>>> library release when the wire protocol enforces peer socket type >>>> checking. >>>> ROUTER -> ROUTER is fine as is ROUTER -> DEALER. >>>> >>>> Alternately, do PUB -> SUB. As of libzmq 3.2, the publisher filters out >>>> the >>>> outgoing messages so only those SUBs that have subscribed to the message >>>> will receive it. This will require you to add a subscription string as >>>> the >>>> first message part for all outgoing messages so the socket can filter it. >>>> >>>> Please read the guide if this doesn't make sense to you yet. There are >>>> lots >>>> of great examples with code. >>>> >>>> cr >>>> >>>> On Nov 13, 2012, at 12:00 PM, Justin Karneges <[email protected]> wrote: >>>>> Inspired by the PUSH/ROUTER question a moment ago, I wonder if it ought >>>>> to >>>>> be possible to match ROUTER and PULL, for one-way directed >>>>> communication? >>>>> >>>>> Currently I am using ROUTER->ROUTER for this, and the receiver just >>>>> ignores >>>>> the envelope. Being able to make the receiver PULL seems like it would >>>>> be >>>>> more natural. >>>>> >>>>> Justin >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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
