[zeromq-dev] Forwarder stops forwarding

Matt Weinstein matt_weinstein at yahoo.com
Wed Jun 16 14:51:46 CEST 2010


Simple is good :-)

For a start, at least for XREQ/XREP queues, I think you can implement  
this at the zmq::device ZMQ_QUEUE concentrator without requiring  
socket mods.  Just tear down both sides when you fail to see a packet  
in time, and use your own synthetic (uuid) identity for OOB  
signaling.  Timing can be a simple third socket which just generates a  
regular heartbeat so you can poll() the timing input along with the  
two streams, that's what I'm using for timeouts.

On Jun 16, 2010, at 8:40 AM, Robin Weisberg wrote:

> 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
>
> Pieter,
>
>>> 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
> (satellite?)
>
> 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.
>
> Martin
> _______________________________________________
> 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




More information about the zeromq-dev mailing list