[zeromq-dev] 0MQ keepalive

[Benjamin]

Hi,

the standard way is the Paranoide Pirate Protocol:
http://rfc.zeromq.org/spec:6

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.

Regards,
Benjamin

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?
>
> So...at the SUB end, if I set ZMQ_TCP_KEEPALIVE/ZMQ_TCP_KEEPALIVE_IDLE
> 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>