Thanks - could you explain a bit more? In the
PUB+SUB-on-same-port-on-same-host situation Pierre described - which
applies to me too - *all* NAKs will be lost, not just some small
fraction of them, if the SUB socket gets opened before PUB, IIUC. Does
that imply that recovery can never happen, regardless of rate limiting,
etc.? I don't want the loss of a single multicast packet to mean that
the whole system will need to be restarted...
If so, then I don't see how I can use zeromq multicast to create a
barrier primitive - that I'd be better off just doing all the low-level
networking myself. That's a pity, if true.
(There would still be one way to do an N-node barrier within zeromq
without a central broker: to give each node its own PUB multicast
address, and have each node SUBscribe to all the others' PUBs. It
seems wasteful of multicast space, and needs more config information to
be passed around, but it would avoid the PUB=SUB port collision. Hmm.)
Thanks for any advice.
Stuart
On 8/6/12 9:08 PM, Steven McCoy wrote:
On 6 August 2012 17:34, Stuart Levy <[email protected]
<mailto:[email protected]>> wrote:
Hmm. So can we tell what is the consequence of that, at ZMQ level, if
NAKs get lost?
PGM continues until the protocol breaks then the window will be
flushed until it can recover. A constant high data rate will likely
not permit the receiver to rejoin, which is why rate limiting is
available.
--
Steve-o
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
