2.4.5 Idle Timeout Of A Connection
To avoid spurious timeouts, the value in idle-time-out SHOULD be half the
peer's actual timeout threshold
So, to me, this means on the @open performative the client should flow (e.g.,)
3 as the idleTimeOut it would like to negotiate, but should actually
-Rafael Schloming r...@alum.mit.edu wrote: -
On Wed, Apr 1, 2015 at 6:00 AM, Dominic Evans dominic.ev...@uk.ibm.com
wrote:
2.4.5 Idle Timeout Of A Connection
Thoughts?
I believe your interpretation is correct. I've certainly noticed idle frames
being sent significantly more
On Wed, Apr 1, 2015 at 6:00 AM, Dominic Evans dominic.ev...@uk.ibm.com
wrote:
2.4.5 Idle Timeout Of A Connection
To avoid spurious timeouts, the value in idle-time-out SHOULD be half the
peer's actual timeout threshold
So, to me, this means on the @open performative the client should flow
Hi,
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'.
So the current impl takes the conservative approach and assumes the peer may
have advertised the actual
-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'