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
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
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
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
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).
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
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
On Wed, Nov 14, 2012 at 8:47 AM, Charles Remes ch...@chuckremes.com wrote:
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 zmq_socket man page is pretty clear about the valid combinations I
think. The
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:
On Wednesday, November 14, 2012 10:08:31 AM Pieter Hintjens wrote:
On Wed, Nov 14, 2012 at 8:47 AM, Charles Remes ch...@chuckremes.com wrote:
The names imply the proper pairings. In what world does ROUTER / PULL make
sense from a semantic standpoint?
How does a PULL socket even send a
On Wed, Nov 14, 2012 at 10:50 AM, Justin Karneges jus...@affinix.com wrote:
Well, or use a separate socket for inbound communication. My application
receives from one socket and sends to another.
How do you know the identity of the PULL socket you're sending to? The
ROUTER socket does not work
On Wednesday, November 14, 2012 11:15:09 AM Pieter Hintjens wrote:
You've not identified any problem with using DEALER except it's not
PULL, which seems arbitrary. You can literally replace ZMQ_PULL with
ZMQ_DEALER in your code and it will work the same.
Ah, okay, I did not think of this.
12 matches
Mail list logo
