On Thu, May 26, 2011 at 11:41 AM, Li, Jia <[email protected]> wrote:
> I see. How about adding a paragraph in the Guide to describe this behavior, > just like it does warn about mixing socket types in devices? Since zmq is > advertised as it-just-works, I was a little disappointed when it didn't and > the user wasn't warned beforehand. Indeed. I didn't even know it worked like this... :) My understanding was that connect/bind were orthogonal to message flows but in fact it seems that's not always the case. We learn something every day... Would you please create an issue in the guide issue tracker, since I'm travelling at the moment so can't do this right away. > So what is the recommended zmq approach for the following type of system? > > A group of 'shouters' frequently and periodically shout out a message. > Shouters don't receive/care about any response for their shouts. > A single 'listener' that takes note of all the shouts currently taking > place. Listener doesn't care about the shouts before it started listening. Timestamps in messages? I'm thinking that perhaps this behavior in the PUB socket (queuing messages even when there are no connections) should be considered a bug... -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
