If the server receives a bunch of DELAYED accounting messages for a client after it has already published a DELAY_UNTIL command for that client, it will send a new DELAY_UNTIL for every accounting message it receives, pushing the delayTS out further and further. This is unnecessary, and possibly a minor sort of DoS vector.
We could delay the publishing of a new DELAY_UNTIL until the current one is close to expiry, and only publish one message at that time, even if more than one accounting message arrived in the meanwhile (the timestamp we publish should be the greatest of all of the timestamps that would have been published). This would reduce the amount of "broadcast traffic" the system would generate.
Downsides are that it requires keeping more server-side state.
If the server receives a bunch of DELAYED accounting messages for a client after it has already published a DELAY_UNTIL command for that client, it will send a new DELAY_UNTIL for every accounting message it receives, pushing the delayTS out further and further. This is unnecessary, and possibly a minor sort of DoS vector.
We could delay the publishing of a new DELAY_UNTIL until the current one is close to expiry, and only publish one message at that time, even if more than one accounting message arrived in the meanwhile (the timestamp we publish should be the greatest of all of the timestamps that would have been published). This would reduce the amount of "broadcast traffic" the system would generate.
Downsides are that it requires keeping more server-side state.