[zeromq-dev] differentiate send() ZMQError cases

Doug Meyer dmeyer at gigaio.com
Thu Aug 1 18:52:34 CEST 2019

Dear zmq community,

I've made a bit more progress. I note that went sending with
zmq.ROUTER_MANDATORY set (1) and the peer not connected, I can observe that
the ZMQError errno property has the value 65 and the strerror property is
"Host unreachable" which is quite nice, though the errno is a mystery as it
does not seem to be related to the POSIX errno values as I expected
(EHOSTUNREACH is 113). As far as I could tell, it seems like libzmq uses
the standard POSIX errno.h values, so I'm perplexed at the value 65 in this
case. Does anybody have insight?

I've not been able to see the case where the HWM is reached, in order to
see what the errno value is for that case. Could somebody please provide me
guidance for HWM setting, please? My case is a ROUTER sending to a DEALER.
The router has zmq.ROUTER_MANDATORY set. On the DEALER sideTCP connection:

slave = context.socket(zmq.DEALER)

I've tried all of the following to get a HWM set to 1 message so that it is
easy to see what happens when the master/ROUTER sends to the slave and the
HWM is reached. The slave connects and then never does a recv().

slave.set(zmq.RCVHWM, 1)
slave.sndhwm = slave.rcvhwm = 1

No matter what I do, I can queue up a lot of messages. I've also attempted
to set the send and receive queue size on the master/ROUTER side at the
same time, but still I can queue up a large number of messages.

Thanks so much for the help!


On Wed, Jul 31, 2019 at 11:55 AM Doug Meyer <dmeyer at gigaio.com> wrote:

> Dear zmq community,
> I'm just getting my feet down on libzmq/pyzmq over here. I've read most of
> the zguide and at least some of the pyzmq and libzmq API information. We're
> python focused over here, and I'm running the following versions for my
> proto work:
> python 3.7.1
> libzmq 4.3.1
> pyzmq 18.0.1
> I've been writing some very basic prototype code with a ROUTER-DEALER
> pattern.
>    - The Master creates a ROUTER socket and binds to a TCP port.
>    - The Slaves create a DEALER and connect to the TCP port.
> The code works fine at a basic level. And my basic discovery and protocol
> stuff is good enough for the proof of concept that I'm building. ZMQ's very
> straight-forward at this basic level, and I'm appreciative of the docs and
> examples. Thanks to the ZMQ team!
> Where I'm getting stuck is related to being able to identify and handle
> some exceptional cases when sending. My questions surround
> blocking/nonblocking send in conjunction with the zmq.ROUTER_MANDATORY
> socket option and the zero (0) and zmq.NOBLOCK send() flag.
> My understanding (and experience) is that if zmq.ROUTER_MANDATORY is NOT
> set, then sends which cannot be sent either because the Identity has not
> registered with the router, or the HWM has been reached, will be silently
> dropped. I see that, and there's no issue there.
> There is discussion in the zmq library docs of the ability to block on the
> send. However, I have not found any way to block on send with pyzmq. If I
> set zmq.ROUTER_MANDATORY and issue the send() or send_multipart() without
> flags, I get zmq.error.ZMQError. Is there a way to make the send block? Is
> there any effective difference between flags=0 and flags=zmq.NOBLOCK,
> because I can't detect a difference behaviorally, though those two flags
> are listed separately in the pyzmq API info for send().
> Probably most critical for me, is there any way to differentiate between
> these send() failures:
> 1. HWM mark reached
> 2. Identity is unknown (the slave with that Identity is not connected)
> 3. All other errors than (1) and (2)
> I can imagine wanting to handle and report case (1) differently than (2),
> as my decision tree and diagnostics are quite different and point to
> distinct failure modes. Does pyzmq support any way to differentiate these?
> Thank you so much for your time.
> Blessings,
> Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20190801/2f936b78/attachment.htm>

More information about the zeromq-dev mailing list