They aren’t reported because they aren’t “errors” in ZMQ. Because the connection can happen independently (asynchronously) from the call to to connect, and because a socket may be connected to a variety of endpoints, the TCP conditions you are concerned about are not exposed to you.
You are asking about detecting a condition that does not exist in the ZMQ architecture. Now, depending on the type of socket and the options set, there might be an error in trying to send to a socket when the other end isn’t present. Or it might not. PUB sockets, for example, need never have a client connected to allow sends to succeed. -- Jim Melton > On Sep 27, 2022, at 10:52 PM, Yuri <[email protected]> wrote: > > Different philosophy is fine. > > But why doesn't ZMQ report connection errors? > When 'Connection refused' (ECONNREFUSED), 'Operation timed out' (ETIMEDOUT) > or several other relevant error conditions arise they should be reported to > the user. Why aren't they reported? > > > Yuri > > > > > > On 9/27/22 21:37, Jim Melton wrote: >> That’s not a bug; it’s a feature. From >> http://api.zeromq.org/2-1%3azmq-connect >> <http://api.zeromq.org/2-1:zmq-connect>, >> >> The connection will not be performed immediately but as needed by ØMQ. Thus >> a successful invocation of zmq_connect() does not indicate that a physical >> connection was or can actually be established. >> >> >> ZMQ sockets are not TCP sockets. There is an unfortunate overloading of >> terms, and what you think you know may not apply to ZMQ. Go back and read >> https://zguide.zeromq.org/docs/chapter2/#The-Socket-API >> <https://zguide.zeromq.org/docs/chapter2/#The-Socket-API> where this is >> described in some detail. >> -- >> Jim Melton > > _______________________________________________ > 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
