[zeromq-dev] Heartbeating in zproto protocol design

[Mario Steinhoff]

Okay, so client-based heartbeat gives me variable intervals per client
which is good to account vor varying client requirements, but when the
server does expiry I would need some kind of heartbeat interval negotiation
in the beginning so the server can know what it should expect here.

I think I'll stick with the server-initiated heartbeat for now, the
implementation works and I do not have multiple link types.
Thanks everyone :)


2016-01-21 21:14 GMT+01:00 Pieter Hintjens <ph at imatix.com>:

> Clients do know what counts as a good heartbeat interval. Sadly it's
> not that simple since servers also need to know what counts as "silent
> so long as to be dead," and can't really trust clients on this.
> There's also the problem of servers restarting (they must tell clients
> to restart any complex protocol).
>
> I'm sure there are several good designs. The one we use in e.g.
> Malamute is quite refined now and the one I'd recommend (it has gone
> through a lot of iterations). However if you have other designs, the
> more the merrier.
>
> -Pieter
>
> On Thu, Jan 21, 2016 at 8:43 PM, Aaron Sokoloski <asokoloski at gmail.com>
> wrote:
> > My guess as to the rationale behind having the client initiate heartbeats
> > and specify the interval is that clients may have widely varying
> appropriate
> > values.  So if you know you've got a high-latency connection, you can
> set a
> > long interval, but if you know your connection is quick and want to find
> out
> > quickly that the connection has been dropped, you can set a short one.
> But
> > this is just a guess.
> >
> > On 21 January 2016 at 13:39, Mario Steinhoff <steinhoff.mario at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> so the zproto README contains a section about protocol design decisions
> >> based on learned experience. It states that the most robust solution
> seems
> >> to be one where the client initiates heartbeats and the server responds
> to
> >> them. If either side finds that there is no response, it will kill the
> >> connection respectively try to reconnect.
> >>
> >> I wrote a server/client implementation where heartbeating is done the
> >> other way around (the server will initiate heartbeats, clients will
> respond)
> >> and looking at some quick superficial kill -9 based tests, that also
> seems
> >> to work very well.
> >>
> >> Are there any drawbacks to this approach that I might have missed or is
> >> this just a matter of taste?
> >>
> >> Thanks
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Mario Steinhoff
https://github.com/msteinhoff
https://twitter.com/msteinhofff
T: +49 173 7265158
In der Gelpe 79
42349 Wuppertal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160122/30e4b3ab/attachment.htm>