Patch 4.4.0 and 10.2.7 are "improving" SendAddonMessage and its logged cousin by making it return a bit more information on failure in the form of an enum, rather than a boolean.
This means that we can now deal with cases where the client is actively throttling comms on a specific prefix. The problem however, is that with this implementation comes a separate change that now means that all traffic is subject to the 10-message-slots-per-prefix system that had been applied to party and raid comms in recent patches.
This means that in cases where there's few addons actually sending data, the default tuning of Chomp's BPS and BURST values is stratospherically high and will result in messages being dropped by the API - so we need to handle the throttling.
Using the result, we'll check if the client has blocked a message due to the per-prefix or per-channel throttle, and if it is we'll requeue it and redistribute bandwidth to the remainder of the messages in the same priority.
There is a bit of gnarly logic here though - the function that sends data out only terminates its loop if there's no data left to send, or if there's not enough bytes left in the pool for us to send the remaining data with. This fights with the whole process of requeueing.
As such - when requeueing messages we put them back into the queue, redistribute the bandwidth, but we don't requeue the queue itself until we're outside of the loop, instead deferring that operation by placing it into a 'blocked queues' table.
We also now don't destroy queues before sending data, but wait until afterwards - this is required because we only want to clean up the 'priority.byName' queue reference only if a queue is in an empty and unblocked state post-send.
These changes should hopefully keep much of the logic in the successful-send and unrecoverable-failure cases the same.
Patch 4.4.0 and 10.2.7 are "improving" SendAddonMessage and its logged cousin by making it return a bit more information on failure in the form of an enum, rather than a boolean.
This means that we can now deal with cases where the client is actively throttling comms on a specific prefix. The problem however, is that with this implementation comes a separate change that now means that all traffic is subject to the 10-message-slots-per-prefix system that had been applied to party and raid comms in recent patches.
This means that in cases where there's few addons actually sending data, the default tuning of Chomp's BPS and BURST values is stratospherically high and will result in messages being dropped by the API - so we need to handle the throttling.
Using the result, we'll check if the client has blocked a message due to the per-prefix or per-channel throttle, and if it is we'll requeue it and redistribute bandwidth to the remainder of the messages in the same priority.
There is a bit of gnarly logic here though - the function that sends data out only terminates its loop if there's no data left to send, or if there's not enough bytes left in the pool for us to send the remaining data with. This fights with the whole process of requeueing.
As such - when requeueing messages we put them back into the queue, redistribute the bandwidth, but we don't requeue the queue itself until we're outside of the loop, instead deferring that operation by placing it into a 'blocked queues' table.
We also now don't destroy queues before sending data, but wait until afterwards - this is required because we only want to clean up the 'priority.byName' queue reference only if a queue is in an empty and unblocked state post-send.
These changes should hopefully keep much of the logic in the successful-send and unrecoverable-failure cases the same.