[zeromq-dev] ROUTER/PULL

[Justin Karneges]

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 <justin at affinix.com> 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 <justin at affinix.com> 
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 <justin at affinix.com> 
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
> >> >> > zeromq-dev at lists.zeromq.org
> >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >> 
> >> >> _______________________________________________
> >> >> zeromq-dev mailing list
> >> >> zeromq-dev at lists.zeromq.org
> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> > 
> >> > _______________________________________________
> >> > zeromq-dev mailing list
> >> > zeromq-dev at lists.zeromq.org
> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> 
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > 
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev