qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Idle Timeout of a Connection
Date Thu, 02 Apr 2015 18:17:32 GMT

----- Original Message -----
> From: "Dominic Evans" <dominic.evans@uk.ibm.com>
> To: proton@qpid.apache.org
> Sent: Wednesday, April 1, 2015 1:55:08 PM
> Subject: Re: Idle Timeout of a Connection
> -----Ken Giusti <kgiusti@redhat.com> wrote: -----
> > I've gone back and forth about what the proper behavior should be for
> > Proton re: idle timeout.
> > 
> > It's that darn pesky "SHOULD"... which means 'recommended', not
> > exactly 'required'.
> Yes, I was similarly surprised that the spec chose to say 'SHOULD' rather
> than
> explicitly stating exactly what the enforcements should be.
> > So the current impl takes the conservative approach and assumes the
> > peer may have advertised the actual timeout (e.g. not half).
> > 
> > To prevent spurious timeouts, idle frames are sent (if necessary) at
> > (timeout)/2 since the last transmitted frame. Sending at exactly
> > (timeout) risks missing the peer's timeout if they did not advertise
> > half their actual timeout. This allows proton to be liberal in
> > respects to how the peer may have implemented idle time, at the
> > expense of potentially doubling the idle frame transmission rate. I
> > feel this is a justifiable tradeoff in an effort to keep connections
> > up in the face of different interpretations of the spec.
> So I'm reasonably happy to leave this as-is. Yes, it does mean we are
> potentially sending empty frames twice as often as we need to, but that's
> never
> going to break the bank and it gives us the security that we will rarely ever
> lose a remote client due to idle timeout.

In all fairness, it could be argued that implementations that do not advertise 1/2 their timeout
value should be fixed.   In that case, changing proton to generate idle frames at the advertised
timeout interval will help uncover these problems.

> > As far as the local setting is concerned, the API doesn't indicate
> > that the value supplied by the application should be half the actual
> > timeout. In other words, users of the API should expect their
> > specified timeout to be used as given, not doubled (unless we expect
> > users of the API to be experts on the standard, which I didn't think
> > was the case).
> I'm less inclined to agree on this one. If we are going for the conservative
> approach in the sending of keepalive frames from proton, I think we should
> also
> go for the conservative approach when enforcing the receipt of keepalive
> frames before closing the session. If I were to write an AMQP 1.0 broker
> based
> upon the spec, I could quite reasonably assume that I only need to send those
> frames as often as the remote end requested them in the @open.
> > Currently, proton does advertise 1/2 of this value, so proton is in fact
> > following the recommendation in the spec.
> Aha, I hadn't spotted that in proton-c's transport.c
> // as per the recommendation in the spec, advertise half our
> // actual timeout to the remote
> const pn_millis_t idle_timeout = transport->local_idle_timeout
> ? (transport->local_idle_timeout/2)
> : 0;
> Currently proton-j just advertises the localIdleTimeout as-is. So perhaps the
> immediate short term fix here is to also have proton-j advertise half the
> supplied localIdleTimeout value to at least make it match what proton-c does.

Ah, so it's possible that having the C impl send twice as often actually hid this discrepancy?

> Cheers,
> Dom
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


View raw message