[zeromq-dev] Router socket messages lost when too quick after connection and how to know if ready to send

Pieter Hintjens ph at imatix.com
Sat Jul 27 18:51:54 CEST 2013

You can use ZMQ_ROUTER_MANDATORY to get an error if a message is
unroutable. But in any case it will never block on sending.

On Thu, Jul 25, 2013 at 9:39 PM, Justin Karneges <justin at affinix.com> wrote:
> On 07/25/2013 12:28 PM, Yannick Hold-Geoffroy wrote:
>> Hello everyone,
>> I've got two questions about router sockets.
>> First, it seems I must wait for a while after connecting a router socket
>> before sending data to its newly connected destination using pyzmq.
>> This simple use case <http://pastebin.com/kPK2ZAc5> shows the problem on
>> my system using pyzmq 13.0.0 with zeromq 3.2.2 (Arch Linux, kernel
>> 3.9.9, GCC 4.8.1): Most of the time it runs correctly and terminates,
>> but sometimes it prints up to around 900 and stall there. Note that
>> adding a sleep before sending (I tried with ~50ms) always make the code
>> works.
>> The router socket always exhibits its POLLOUT flag even if the
>> connection isn't ready to send to a newly connected peer. Is there a way
>> to ask the zeromq socket when it's ready to accept messages to a given
>> host without dropping them, aside from manually specifying a sleep?
>> My second question is about sending. Still using a router socket, you
>> could set as destination anything you'd like (even if the socket isn't
>> currently connected to a peer with this identity). Is there a way to
>> know if a connection is currently available for sending (ie. the message
>> will be sent immediately, like POLLOUT for a given peer)?
>> I've tried setting the socket's ZMQ_SNDTIMEO to zero and try sending
>> using the ZMQ_NOBLOCK to see if it would raise (in pyzmq) an ZMQ_EAGAIN
>> error, but it always seems to pass without problem even when there is
>> nobody listening. A minimal code exhibiting my comprehension of how it
>> should work can be found here <http://pastebin.com/zQE2Awt4>. Is there
>> something I haven't understood about how it's supposed to work?
> Hi Yannick,
> The simple answer is that ROUTER has a drop policy, not a blocking one.
> And there is not a way to know with pure 0mq whether or not there is a
> recipient available. That is something you would need to build on top.
> Justin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list