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 respectivel > <http://www.dict.cc/englisch-deutsch/respectively.html>y 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
