> > 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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
