[zeromq-dev] Unreasonable behavior of a socket when connection can't be established. How to enable the blocking mode on a socket?

Bill Torpey wallstprog at gmail.com
Wed Sep 28 14:20:50 CET 2022


Hi Yuri:

There are a couple ways to deal with the situation(s) you describe, which can be used together.

1.  	You can set options on the socket to change ZMQ’s default reconnection algorithm:

ZMQ_RECONNECT_STOP_CONN_REFUSED
ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED
ZMQ_RECONNECT_STOP_AFTER_DISCONNECT

These options were introduced in ZMQ 4.3.3.  Unfortunately, these options are in DRAFT mode and are not documented on the ZeroMQ website.  You can find out more by checking out the PR's that introduced these options:  https://github.com/zeromq/libzmq/pull/3960 <https://github.com/zeromq/libzmq/pull/3960>, https://github.com/zeromq/libzmq/pull/3831 <https://github.com/zeromq/libzmq/pull/3831> 

2.	   You can use the socket monitor API to be notified of low-level events that take place on the socket: http://api.zeromq.org/master:zmq-socket-monitor <http://api.zeromq.org/master:zmq-socket-monitor>.  The downside of this approach is that socket events are asynchronous — several of the events document this, e.g., “there is no guarantee that the FD is still valid by the time your code receives this event”.

Hope this helps.

Bill


> On Sep 27, 2022, at 5:09 PM, Yuri <yuri at rawbw.com> wrote:
> 
> The code below successfully "connects" to a bogus host and then waits for response, when in reality the connect(2) call returned errno 36 (Operation now in progress) and connection wasn't successful.
> 
> This behavior hides the real problem: inability to connect to a host.
> 
> The correct behavior for a non-blocking socket would be to wait for connection to complete or fail, but this doesn't happen for some reason.
> 
> 
> The situation is worse when the host is changed to localhost, when it is known that this port is closed. This program still waits forever, when the correct behavior is to fail with 'Connection refused'.
> 
> 
> It appears that libzmq sets the O_NONBLOCK option on all sockets, which causes such behavior.
> 
> How to change the socket back to the blocking mode such that 'connect' would behave the same way as the original POSIX connect(2) call would in the blocking mode?
> 
> 
> I also believe that the behavior described above constitutes a bug in libzmq. The connect call should time out after some number of seconds and should fail with 'Timeout expired while trying to connect to xx' or 'Connection refused'.
> 
> 
> 
> Thanks,
> 
> Yuri
> 
> 
> 
> 
> 
> ---begin code---
> 
> import zmq
> 
> bogus_address = "1.2.3.4:17882"
> 
> context = zmq.Context()
> socket = context.socket(zmq.REQ)
> 
> print("connecting to bogus address: "+bogus_address)
> res = socket.connect("tcp://%s" % (bogus_address))
> print("connected to bogus address")
> 
> print("sending string...")
> socket.send_string("something")
> print("sent string")
> 
> print("waiting for acknowledgement")
> socket.recv(4096)
> print("acknowledgement arrived")
> 
> ---end code---
> 
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20220928/7c89e0e4/attachment.htm>


More information about the zeromq-dev mailing list