-----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
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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU