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

[Matt Weinstein]

Is this just a distributed state management problem -- namely, push  
the changes to one or more reference stores, and get published  
updates ...?

You just have to push a stream and manage serializability /  
serialization / conflict detection etc.

Quick techniques include using straight delta messages on data ("add  
$10 to account XX" vs. "change balance of account XX to $25"), delta  
messages on idempotent data ("change birthdate from ZZ/ZZ/ZZ to YY/YY/ 
YY" -- conflicts are detectable under appropriate rules), or several  
classes of timestamps, version clocks, sequence numbers, etc.

IMO the transport (REQ/REQ, PUB/SUB, etc.) that the updates use is  
irrelevant for semantics, the choice is dictated by network topology,  
performance, etc.

On Aug 31, 2010, at 7:15 AM, gonzalo diethelm wrote:

>>> 2) Is it "safe" to do PUB/SUB over a "tcp://" endpoint, or should I
> be
>>> looking at one of the multicast protocols? Does it simply come down
> to
>>> network bandwidth usage? Is there any case when tcp would be
> preferable
>>> for a PUB/SUB socket?
>>
>> TCP is much simpler to use and unless you are doing high volumes with
>> filtering on messages, there's no point in using multicast.  Put it
>> like this: start with TCP and look at multicast if you have a network
>> bandwidth issue.
>
> 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?
>
>>> 3) I think I can take care of any timing issues (such as delays
>>> connecting the PUB/SUB sockets) if my client first sends a "client
>>> coming up" message down the PUSH socket and waits until it gets a
>>> "everything is ready for you" message on the SUB socket (probably
> with a
>>> UUID to pair the two). Right?
>>
>> Right.
>
> 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?
>
> -- 
> Gonzalo Diethelm
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev