[zeromq-dev] ROUTER/PULL

Charles Remes chuck at chuckremes.com
Wed Nov 14 00:47:08 CET 2012


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 <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




More information about the zeromq-dev mailing list