[zeromq-dev] Forwarder stops forwarding

Robin Weisberg robin at scout-trading.com
Wed Jun 16 14:40:55 CEST 2010

My vote would be to just keep it simple. Debugging and reading a tcpdump will be more confusing if you have to figure out why a heartbeat was/wasn't sent based on fancy heuristics.

I like the idea of sending if there hasn't been any other message sent in the past X milliseconds and make X a socket option. 

-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Martin Sustrik
Sent: Wednesday, June 16, 2010 1:30 AM
To: 0MQ development list
Subject: Re: [zeromq-dev] Forwarder stops forwarding


>> Use a one-way keep-alive (rather than a round-trip heartbeat) and make
>> it adaptive. Each side would just look at their average sends per
>> second, and maintain a fraction of that rate.  It would be easy to
>> measure the rate by sampling a counter...
> In fact if one party is sending messages, it does not need to send
> heartbeats (messages count as "alive").  So a plausible solution is
> that each peer sends heartbeats only when it's not sending messages,
> and it does this at a rate that matches the previous message rate
> (maybe 1% of it), slowing down in a curve.  The recipient can detect a
> dead peer by seeing a sudden fall to zero in incoming messages, rather
> than a slope.

That's a nice heuristic.

The obvious problem are with high-bandwidth networks with peaky latency 

High bandwidth means that the rate computed will be very high. However, 
latency peak would create a sudden interval with no data.

Let's think about it a little more.

One thing that may be useful is using byte-count rather than 
message-count to estimate the rate. That would prevent disconnection in 
case when large message is sent after sequence of short ones.

zeromq-dev mailing list
zeromq-dev at lists.zeromq.org

More information about the zeromq-dev mailing list