[zeromq-dev] ROUTER/PULL

[Pieter Hintjens]

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