[zeromq-dev] Heartbeats and/or keep-alives

[Marcelo Cantos]

On Wed, 13 Oct 2010 at 5:13 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Wed, Oct 13, 2010 at 4:26 PM, Martin Lucina <mato at kotelna.sk> wrote:
>
> > In Marcelo's specific case he will need to add it into other traffic;
> > adding an extra socket won't help since his network will still declare
> the
> > normal idle connection dead, so the hearbeat (or in this case keepalive)
> > needs to travel along each TCP connection that might become idle.
>
> Good point.  So for sub and pull sockets (and others probably) 0MQ
> will eventually have to do heartbeating itself.
>

Thank you both for the informative responses. I suspected that I would have
to build my own keep-alive mechanism for now, and it will be great to see
some advice in this regard appearing in the user guide.

With my meager experience of 0MQ as a caveat, I would agree that this kind
of facility definitely belongs under the hood, regardless of which messaging
pattern one is using, since keep-alives apply to the underlying transport,
and 0MQ users generally don't see that level. Since I have no idea what TCP
connections are established — or when — it is difficult for me to decide
when and how often to send keep-alives. As a concrete example, how do I know
to stop sending 0MQ keep-alive messages when my peer goes down? If I keep
sending without regard for this, and I have a HWM in place, I will soon
start dropping all messages, not just the keep-alives.

Coming at it from another angle, I understand that TCP itself supports
keep-alives via empty ACK packets. Would a very simple solution be to expose
the SO_KEEPALIVE socket option via a corresponding ZMQ_KEEPALIVE? Of course,
this would only be supported when using "tcp://..." bindings, which may be
the only time you'd need it, anyway.


Cheers,
Marcelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101014/d0ecf1a6/attachment.htm>