[zeromq-dev] 0MQ keepalive

Benjamin benjamin.l.cordes at gmail.com
Sat Nov 1 09:02:03 CET 2014


the standard way is the Paranoide Pirate Protocol:

The Guide discusses this in chapter 4: http://zguide.zeromq.org/php:chapter4

For a heart-beating for publishers I think you have to define your
use-case. As an example, say the client discovers that the service is down,
can he switch to another service? In a P2P context this happens all the
time - one peer discovers another peer is dead and switches. Or in a
client/server context, the client might just wait a bit because of overload
on the server. So "dead" can mean different things.


On Sat, Nov 1, 2014 at 3:50 AM, Meng Zhang <jammy.linux at gmail.com> wrote:

> Hi, @there,
> Following is the issue we encountered in our production env:
> We are using ZeroMQ PUB/SUB pattern,
> but the weird thing is that at the SUB  end, netstat showed the zeromq
> socket is in ESTABLISHED state,
> while at the PUB end, the LISTEN socket is still there, but the
> corresponding ESTABLISHED socket disappeared.
> Given there is not built-in hearbeat mechanism in ZeroMQ,
> for such situation, what's the best practice to leverage TCP keepalive to
> dectect this issue?
> properly,
> * if I choose to use czmq, how can I assert the socket is dead thru the
> zstr_recv()?
> * if use libzmq directly, how can I do the same thing by zmq_msg_recv()?
> Regards,
> Meng
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141101/282c4675/attachment.htm>

More information about the zeromq-dev mailing list