[zeromq-dev] PUB doesn't discard msg when no SUB

[Li, Jia]

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.
 
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.
 
Thanks!

________________________________

From: zeromq-dev-bounces at lists.zeromq.org
[mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Ian Barber
Sent: Thursday, May 26, 2011 2:13 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] PUB doesn't discard msg when no SUB




On Thu, May 26, 2011 at 5:57 PM, Li, Jia <jia.li at credit-suisse.com>
wrote 

	The problem I see is that if the SUB starts after the PUBs, it
still receive all the messages sent before. This seems to contradict to
what the documentation said.

	However, if I have only one PUB and one SUB, and I reverse the
connect/bind by having PUB bind() and SUB connect(), I get the
documented behavior in which SUB doesn't receive historical messages.

It's just as artifact of how the connection handling works - if you
connect the PUB it doesn't discard the messages as it is automatically
trying to establish the connection - the PUB that is binding knows it
has no connections so drops the messages. 

Ian 


=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110526/9ec9f454/attachment.htm>