-----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. > 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. 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
