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 second - 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 approach does have a slight downside in that in some cases there may be additional transmission latency. Specifically, if we attempt to send a message and the API blocks it due to throttling then there's a chance that had we waited one game tick longer the prefix would have permitted a transmission. However as the queue is now marked as blocked, the transmission is delayed by potentially a whole second until the integration timer ticks. This could be alleviated somewhat if we either lowered the integration period of blocked pipes from 1 second to something a bit lower, or possibly just by outright removing it. If the timer were removed then it's worth noting that the reintegration of blocked pipes puts them at the _end_ of the transmission ring; which conveniently means that unblocked pipes are always prioritized. As such it may not be a bad idea to just forego the timer and let this implicit sorting take the reins. Aside from prefix throttling, there's a few other small changes in this PR that were additionally discussed; - 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. - Compatibility with the pre-8.0 *global* SendAddonMessage API was removed as it's no longer needed.
- Loading branch information