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

Martin Sustrik 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 
not established.

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.

Martin



More information about the zeromq-dev mailing list