Robbie beat me to it... In proton-c pn_transport_set_idle_timeout sets the actual local timeout interval.
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. :/ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=blob;f=proton-c/src/transport/transport.c;h=cdecfd291139acfb1c90698677abc0efc4056f50;hb=HEAD#l2539 ----- Original Message ----- > From: "Robbie Gemmell" <[email protected]> > To: [email protected] > Cc: [email protected] > 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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
