-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature spec: Add spec point for incremental backoff and jitter #1445
Conversation
e083ab2
to
3738d32
Compare
h3(#backoff-jitter). Incremental backoff and jitter | ||
* @(RTB1)@ For connections in the @DISCONNECTED@ state and realtime channels in the @SUSPENDED@ state the time until retry is calculated as the product of the initial retry timeout (for @DISCONNECTED@ connections this is the @disconnectedRetryTimeout@, for @SUSPENDED@ channels this is the @channelRetryTimeout@), the backoff coefficient as defined by "@RTB1a@":#RTB1a, and the jitter coefficient as defined by "@RTB1b@":#RTB1b. | ||
** @(RTB1a)@ The backoff coefficient for the nth retry is calculated as the minimum of @(n + 2) / 3@ and @2@. | ||
** @(RTB1b)@ The jitter coefficient is a random number between 0.9 and 1. The randomness of this number doesn't need to be cryptographically secure but should be approximately uniformly distributed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider a wider range, eg (0.8, 1)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok cool, I've changed it to this in b7534ec and updated the description.
e402cf8
to
b7534ec
Compare
I wonder if it's worth putting this example in the spec to avoid any ambiguity, or perhaps even specifying it as a test fixture? |
@lmars I can't think of a way to do this without kind of bloating the spec point, and personally I think it would be a bit too much detail (I will include that example in the GitHub issues to implement this feature if that helps?). If you disagree would you mind making a suggested change? |
I think we should put some examples in the https://github.com/ably/ably-common/tree/main/test-resources Then SDKs can use those as test fixtures, so we know all SDKs implement the feature in exactly the same way, much like we do for encryption. That doesn't stop us merging this PR though, so I've approved. |
I've created ably/ably-common#153 to address lewis's comment regarding testing |
Expression to calculate upper and lower bounds for generated values using
|
Resolves #832
RTB1a
The backoff coefficient described in
RTB1a
can be calculated in javascript like so:The idea of this is modelled off of the '15 -> 20 -> 25 -> 30' sequence suggested by paddy in #832. For the default retry client options this will give that exact sequence, and if users configure their client to use a different retry time this will give an equivalent sequence of longer retry times proportionate to their configured retry time.
RTB1b
The jitter coefficient described in
RTB1b
can be calculated in javascript like so:The reason I chose not to allow for the jitter coefficient to be a value higher than 1 is that this could result in a retry length longer than 30s for the 4th retry and beyond. A side effect of this is that all initial retry attempts will be slightly shorter than they would have been prior to this change. It could also work to allow for a jitter coefficient between 0.8 and 1.2 and just say that the retry time is the minimum of that calculation and 30s.
RTB1
The overall retry time calculation would look like:
The following code can be used to test it:
Which, with an
initValue
of 15 (seconds) will print something like: