Thanks for the explanation. The original grouping by pattern makes it more clear why things work they way they do.
On Wednesday, November 14, 2012 09:57:54 AM Pieter Hintjens wrote: > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
