On Tue, 2016-09-27 at 15:37 -0400, Alan Conway wrote:
> I want to clarify and document the meaning of these terms for our
> APIs,
> presently I can't find anywhere where they are documented clearly.
> 
> The AMQP spec says: "Each peer has its own (independent) idle
> timeout.
> At connection open each peer communicates the maximum
> period between activity (frames) on the connection that it desires
> from
> its partner.The open frame carries the idletime-out
> field for this purpose. To avoid spurious timeouts, the value in
> idle-
> time-out SHOULD be half the peer’s
> actual timeout threshold."
> 
> In other words: if I send you an "open" frame with idle-time-out=N
> that
> means *you* should not wait for longer than N milliseconds to send a
> frame to me. It does not mean *I* will close the connection after N
> milliseconds, I SHOULD be more patient and wait for N*2 ms to avoid
> closing prematurely due to minor timing wobbles.
> 
> I think the choice of name is slightly ambiguous but the spec is
> clear
> on the semantics, so it's important to document it to remove the
> ambiguity.
> 
> Anybody disagree?
> 

Sigh. Sadly proton-C interprets "idle-timeout" differently depending on
which end of the connection you are on:

      // 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;

So in proton, pn_set_idle_timeout does NOT mean set the AMQP idle-
timeout value, it means set the local "receive timeout" value and send
half that as the AMQP "send timeout" for the peer.

I'm tempted to use a new term in the Go API: "heartbeat". To me that
clearly means the "send timeout" (hearts beat, they don't listen for
beats) so it coincides with the meaning of the AMQP "idle-timeout", but
without the ambiguity that is exacerbated by proton interpreting it
both ways.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to