Robbie beat me to it...

In proton-c pn_transport_set_idle_timeout sets the actual local timeout 

The value of the Open frame's idle-timeout field is 1/2 the value set by 
pn_transport_set_idle_timeout, as suggested by the spec.


----- Original Message -----
> From: "Robbie Gemmell" <>
> To:
> Cc:
> Sent: Monday, October 17, 2016 12:32:13 PM
> Subject: Re: API and terms: idle-time-out and heartbeat intervals.
> On 17 October 2016 at 16:57, Alan Conway <> wrote:
> > On Fri, 2016-09-30 at 14:40 +0100, Rob Godfrey wrote:
> >> I don't think it's a bug - it's a completely valid (if chatty)
> >> choice.
> >>
> >> To my mind the semantics of the field are this:
> >>
> >> The sender of the open frame is saying "if I do not receive any data
> >> for this period of time, I reserve the right to assume that you are
> >> no
> >> longer functioning correctly"
> >> On receiving this information, the peer should decide on a strategy
> >> that ensures to the best of its ability, that if it is functioning
> >> normally it will be generating data sufficiently frequently that the
> >> condition does not occur.  If this peer knows that it is susceptible
> >> to delays outside its direct control (such as garbage collection
> >> pauses) it should take account of this in how often it schedules
> >> sending heartbeat frames.
> >> At the same time, the sender of this value should give some leeway
> >> before actually shutting down to account for unexpected transport
> >> delays, or processing delays on its side.  Since it is unaware of the
> >> nature of the allowances made at the peer, it may decide to be
> >> particularly generous in the leeway it grants.
> >>
> >> I think the spec mentioning a ratio (such as twice) is massively
> >> unhelpful.
> >>
> >> In terms of the API - what is the applications intent in setting the
> >> value?  Is the intent to ensure transport activity within a specific
> >> period, or to set a hard limit on how long the library will wait
> >> before generating some sort of timeout exception?
> >
> > My guess is that in terms of the API, the application's intent in
> > calling "set_idle_timeout(T)" is to set the formally-specified AMQP
> > value called "idle-timeout" to T. I don't think anybody's first reading
> > of the API doc or the spec would suggest to them that if they want to
> > set a wire timeout of T they actually need to call
> > set_idle_timeout(T*2) on one side of the connection and it will
> > magically come out as T on the other.
> >
> > Spec wording aside, does anybody actually disagree with that?
> > <snip/>
> If you dont consider the spec wording, I think that an application
> intent in calling a method named setIdleTimeout would likely be to
> consider it as the time after which something is considered timed out
> if it is idle. This is what it does now.
> If we called it setOpenFrameIdleTimeout, I think they could definitely
> expect it to set the value populated in the Open frame, before needing
> to read the API to see when things are actually considered timed out.
> If we called it setHeartbeat I think we could resonably expect folks
> going either way on their thinking of what it will do before reading
> the API to find out what it actually does.
> In the end, its simply not the clearest area due to the spec wording,
> which most users will never read, and I think its fine so long as our
> methods/config actually document what they do.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to