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 <[email protected]>: > 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 > -- Mario Steinhoff https://github.com/msteinhoff https://twitter.com/msteinhofff T: +49 173 7265158 In der Gelpe 79 42349 Wuppertal
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
