[zeromq-dev] Architectural question: REP/REP vs. PUB/SUB

[Pieter Hintjens]

On Tue, Aug 31, 2010 at 1:15 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:

> Is it correct to say that PUB/SUB is as "safe" as, say, REQ/REP, in the
> sense that one has the same guarantees that a message sent down the pipe
> will actually make it to its destination? Or is PUB/SUB somehow less
> "reliable"? From the fact that both use plain TCP (in this use case), I
> would think the guarantees are the same, right?

The guarantees depend on whether or not SUBs are connected and to what
extent you synchronize that so that PUBs only send when they know a
SUB is listening.

> Great. Now another question on PUB/SUB. If I have a set S1 of processes
> that want to publish messages to another set S2 of processes, I know I
> would have to use a forwarder: all processes in S1 would have a PUB
> socket connected to the forwarder's incoming SUB socket; the forwarder's
> outgoing PUB socket would forward the messages to all processes in S2,
> each of them having an incoming SUB socket. This is 0MQ 101.
>
> Now, notice that processes in S1 must know the single address for the
> forwarder's incoming socket. This leads me to the following question:
> what do I gain by using a PUB socket for processes in S1? As I see it,
> each of these processes could have a PUSH socket sending messages to the
> forwarder's incoming PULL socket; the forwarder would then use its
> outgoing PUB socket as usual. What do I lose by going this way? Why
> would PUB/SUB on S1 still be preferable?

PUSH does round-robin distribution.  If you are sending to a single
device, then that is equivalent to XREQ or PUB, all of which will do
the same (assuming the device is connected).  SUB and PULL will work
the same except for the filtering on SUB.

There is no advantage in any of these, it's up to you what feels most
natural.  You might end up with devices that read from a PULL and send
to a PUB but that's fine IMO.

-Pieter

>
> --
> Gonzalo Diethelm
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>



-- 
-
Pieter Hintjens
iMatix - www.imatix.com