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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
