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 <[email protected]> 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 > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
