ZMQ socket connection timeout

Question

I'm using C++ binding for ZMQ (cppzmq) and I'm trying to set the connection timeout of TCP socket using a .setsockopt()-method like this:

int connectTimeout = 1000;
socket.setsockopt(ZMQ_CONNECT_TIMEOUT, &connectTimeout, sizeof(connectTimeout));
socket.connect(clientConfiguration.uri);

However, I dont see anything (exception thrown?) happening until code reaches actual .send()/.recv() on the socket. Just to make sure the socket has a chance to throw I put a sleep between .connect() and .send() methods.

According to the documentation .zmq_connect() just enters a READY-state without making actual connection to the endpoint. So the question is when and how I should experience the connection timeout?

Cateyed

what is your transport? – Schulze

TCP, question updated – Cateyed

I don't see mentions of zmq_connect being asynchronous in the docs. Would you mind pointing me to it? – Wherefore

api.zeromq.org/3-2:zmq-connect - "for most transports and socket types the connection is not performed immediately but as needed by ØMQ. Thus a successful call to zmq_connect() does not mean that the connection was or could actually be established. " – Cateyed

With all due respect, Sir, what is the design-side ( technology ) reason to keep the design under the API v3.x given the recent stable is ages ahead - somewhere above 4.2.2+ in 2018/Q2? ( more on this + possible solution vectors of attack below ) – Gruel

@user3666197, does it make any difference? does the zmq_connect behaves differently here api.zeromq.org/4-2:zmq-connect? – Cateyed

Answer 1

So the question is when and how I should experience the connection timeout ?

When ?

Well, actually never directly as this is just the API-exposed setting of ZeroMQ Context()-instances' internal Finite-State-Machine modus operandi ( here the .setsockopt() sets the selected transport-class behind-the-API-curtain ISO-OSI-L3 details ).

How_{( if at all )} ?

Well, there are some other .setsockopt() details, that ( if put on ) may indirectly sense the impact of the set ZMQ_CONNECT_TIMEOUT connection timeout. Here again, only indirectly, by a modified FSM-behaviour, i.e. in a way, how the .Context()-engine instance will happen to respond to such event ( all purely internally, behind the Curtain of API - that's why we methodologically use the API method for separation of concerns, don't we ? ).

For further details ref.:

• API details about ZMQ_IMMEDIATE,
• API details about ZMQ_RECONNECT_IVL,
• API details about ZMQ_RECONNECT_IVL_MAX.
  _{( API versions evolve, be aware that not all distributed-system agents share the same ZeroMQ API version. So best remember the Zen-of-Zero and feel free to re-use the anxient designers' directive #ASSUME NOTHING. )}

---

A TRAILER BONUS :

If not familiar with the ZeroMQ instrumentation, one may find useful this 5-seconds read into the main conceptual differences in the [ ZeroMQ hierarchy in less than a five seconds ] Section,

_{( courtesy Martin Sústrik, co-father of both ZeroMQ + nanomsg. Respect! )}

Gruel

Hm... sounds like it doesnt solve my problem of the irresistible desire to be aware of connection problems :) Should I pursue other directions like zmq_socket_monitor to get notified of connections problems and such? – Cateyed

" irresistible desire " ??? Cool. Doable. Seriously. Just go get it done, simply fork + re-factor the core-lib and you are done, man. Nothing else matters :o) A similarly motivated effort was spent on nanomsg the younger ZeroMQ sister, where API got recently extended to have a call to a nn_get_statistic( aSock, NN_STAT_CONNECT_ERRORS ), which thus seems as an immediate proxy-solution, if you have a design-side option to step forwards to use the nanomsg instead of ZeroMQ for your distributed-system under-design. >>> nanomsg.org/v1.1.4/nn_get_statistic.html – Gruel

Great idea, gimme a second I will rewrite the zmq the right way. – Cateyed