[zeromq-dev] Forwarder stops forwarding
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.
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