Justin, The combinations are not arbitrary. There's an explanation here: http://zguide.zeromq.org/page:all#Request-Reply-Combinations.
Firstly, you can replace REQ with DEALER, and REP with ROUTER, to turn a synchronous REQ-REP into a partially or fully asynchronous flow. Secondly, you can combine DEALER to DEALER and ROUTER to ROUTER to get two new patterns. The legal combinations are formally defined in the zmq_socket man page. The original design ideology, which was accurate IMO, was that each low-level "pattern" was a separate package. Thus, PUB+SUB, PUSH+PULL (pipeline), PAIR, REQ+REP+DEALER+ROUTER. We've been extending the protocol to announce each peer's socket type, to let us catch invalid combinations. The public spec in zmq_socket[3] defines what kind of future compatibility we promise. Since it states that ROUTER+REQ is valid, this will always work. But since it does not allow ROUTER+PUSH, we're free to break that in the future. Hope this helps to understand the reasoning here. -Pieter On Wed, Nov 14, 2012 at 7:54 AM, 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
