Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add support for per-prefix transmission throttling
In patch 4.4.0 and 10.2.7 Blizzard have tightened the restrictions on addon comms to add a per-prefix throttle across all chat types, effectively restricting them to one message per second with a small accrued burst capacity. The SendAddonMessage APIs now return an enum result code which includes information if this client-side throttle has been applied to a submitted message. With it, we can now properly handle throttling in CTL and avoid situations where addon messages would be dropped for exceeding it. This PR takes into consideration the discussion on Discord and takes a slightly different approach to the other open one by instead implementing the concept of a "blocked" pipe. A pipe enters the "blocked" state whenever a message at its head is attempted to be sent off, and a throttle result code is returned from the API. When transitioning to this state, the pipe is removed from the transmission ring of its parent priority and is instead placed into a separate (and new) blocked ring. This prevents the despool logic from seeing blocked pipes and pointlessly attempting to re-send on them. Periodically - currently every 0.35s - the contents of the blocked rings in each priority are reintegrated back into the transmission rings, allowing us to attempt re-transmission of queued messages. This means there may be some added latency when a prefix entered a blocked state if the API was about to perhaps unblock it, but this also allows us to reallocate bandwidth that would be consumed by priorities that are fully blocked to others that can more readily use it. The value of 0.35s was chosen almost arbitrarily and could be tuned later if found to be a bit high. It's important to also note that we specifically don't consider the 'ChannelThrottle' return code a retryable error condition. The reasoning here is that this throttle isn't new, and the API can return this value but still sometimes send off the message albeit subject to additional server-side throttling checks - and also at the time of writing, a server-side bug that causes it to more aggressively throttle than it actually should. Aside from prefix throttling, there's a few other small changes. - Failure to send a message either due to an error or throttling no longer consumes bandwidth that had been allocated to a priority. - Priorities that enter a blocked or empty state now release their bandwidth back to the global pool for redistribution immediately, instead of waiting until there's no data queued up whatsoever. This is required to deal with edge cases involving priorities sending many small messages on one prefix infinitely accumulating bandwidth. - Transmission logic has been centralized into a new PerformSend function to minimize the number of call sites individually needing to remember to toggle boolean variables with each Send call. - Queued transmissions no longer apply checks to see if the player is in a group or raid. The API has dedicated return codes for this condition and has been tested to not trigger erroneous system message spam if attempting to send a message to either chat type while not being in a group. This is not the case for guilds, however the library never checked this case previously so one hasn't been added. - User-supplied callbacks are now supplied an accurate 'didSend' parameter that will be false if the API returns a non-throttle-related error code. - User-supplied callbacks are additionally now supplied the new result code as a third parameter. For Classic Era, we synthesize one from a subset of the enum values based off the boolean result that the API will still be providing there for now. - User-supplied callbacks no longer let errors blow things up in an uncontrolled manner by being subject to securecall wrapping. This is also consistently applied irrespective of whether or not the send itself was immediate or queued. - Some compatibility with the pre-8.0 global SendAddonMessage API was removed as it's no longer needed.
- Loading branch information