Has someone experiences with JeroMQ and 'Connection Heartbeating'?
We already use application-level heartbeating but I was curious whether the following could help/simplify this. The README.md states that it follows the ZMTP/3.0 but heartbeating seems to be part of ZMTP/3.1. How much of this is already working in JeroMQ?
The spec defines only one 'ping-ttl' timeout which I guess is the one mapped to
Socket::setHeartbeatTtl(int) (A). What is the difference w.r.t. 'Socket::setHeartbeatTimeout(int)' (B)? Is this an asymmetric time-out definition ala
Socket::setHeartbeatTtl(int)setting the frequency of the transparent pings that my client sends under the hood?
For example if I choose the following socket parameters:
socket.setHeartbeatTtl(1000); socket.setHeartbeatTimeout(3000); socket.setHeartbeatIvl(200);
Does this imply, that my client sends pings every 200 ms, if the other client/server does not reply within 1000 ms my client socket closes, and if I haven't sent any (new) pings for 3000 ms the other client/server may (or is forced to) close the socket on it's side? Does this work for all tcp-based socket combinations?
Any clarification/confirmation would be much appreciated.
grabber, have you looked at the Majordomo protocol? It solves this pattern in what I think is an elegant way.
"This broker connects a set of clients to a set of workers who register particular "services". Client requests are then sent to workers according to their availability, and replies sent back to the original clients."
socketpair. The system call creates a connected pair of sockets that provide the properties you want, which can be passed to a subprocess using typical methods--that is, inherited from a fork, or sent along another established Unix socket. zmq can make use of that kind of socket via the
ZMQ_USE_FDsocket option, but only when binding. There's currently no equivalent facility for the connecting peer.
listencalled on it so incoming connections can go to the ZMQ protocol machinery. The mentioned use case is systemd socket-activated services, where the listening socket gets created by the service supervisor and the service itself is lazily created with the socket already set up the first time something connects.
@wartek69 re. overengineering, it can be a bit daunting but ZMQ is very well designed in the sense of "take it or leave it" features. Especially with good bindings.
@detly sorry for the late response, not very active on here, just saw your @ :D. I've implemented it using dealer <-> dealer and it seems to work without any issues, some example code can be found here: https://github.com/wartek69/zeromq_dealer_client_server