A secondary reason why server based may be favoured is that clients don't necessarily know when data was actually "sent" on say unidirectional (streaming) clients. A common implementation of heartbeats is "if I havn't received/sent a message in n time then send heartbeat" (eg if you are actively receiving stuff no need to heartbeat). This style tends to work from the server side to handle varying per client, a message is often supported to negotiate the time period with server (usually its something like client reqs 1 second but server determines what it will actually be).
On Thu, Jan 21, 2016 at 9:14 PM, Pieter Hintjens <[email protected]> wrote: > 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 -- Studying for the Turing test _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
