[zeromq-dev] Heartbeating in zproto protocol design

[Greg Young]

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 <ph at imatix.com> 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 <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



-- 
Studying for the Turing test