[zeromq-dev] PUB doesn't discard msg when no SUB
sustrik at 250bpm.com
Thu May 26 21:18:52 CEST 2011
On 05/26/2011 08:49 PM, Pieter Hintjens wrote:
> On Thu, May 26, 2011 at 11:41 AM, Li, Jia<jia.li at credit-suisse.com> 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...
Here's some background: The algorithm was implemented the "consistent"
way first. The connecting side dropped messages if the connection was
This caused a lot of puzzlement among users. You would expect following
sequence of commands to actually send the message to the peer:
zmq_connect (s, "...");
zmq_send (s, msg);
The problem is that connecting is asynchronous and takes certain amount
of time. Thus, when send is executed, the connection doesn't exist yet
and the message is dropped.
So, what I did to make the behaviour more user friendly was to create a
"queue" as soon az zmq_connect() is called. It is then attached to the
actual network connection when it is established.
There was even some talk on doing a similar trick on the bind side
(creating a "queue" as soon as bind is called and assigning it to first
incoming connection later on), which would make the behaviour consistent
on both ends of the connection. This was not implemented yet though.
More information about the zeromq-dev