----- Original Message ----- > From: "Dominic Evans" <dominic.ev...@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 <kgiu...@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 > > -- -K
