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