This Commit contains a couple of changes to the anti-spam and an initial implementation of a "Serial commands" batch queue.
I have a couple of small issues with it.
The first part is that the serial commands addition is not applying to sufficient commands. Specifically, it should also apply to all drawing commands that use the /mark command (eg: /cuboid,/fill etc) This would fix the long standing race issue with those commands.
In addition, long running commands, such as /replaceall would likely be best to be run on this batch queue.
Next, IMO, overloading of "Serial commands" with the double counting of the /place command in the anti-spam is really not a good idea. I guess that the source problem that this is supposed to solve is that the /place command is one of the few commands where it's likely that there can be sufficient load to have the backgrounded commands overlapping to a large extent.
For this issue (huge numbers of /place commands from multiple clients) I would suggest that the /place command is instead double counted by adding each run to the block-spam-check as well as the normal command spam check. This would fix the problem at source by removing the main advantage (Spam counters) for using it in parallel to normal setblock packets (/place is still needed to place physics blocks, doors, though). This will also have lower layer advantage in that SetBlock packets are considerably smaller than place command containing Chat packets.
Lastly, I feel that this change increases the need for a /trust command for cmd-spam as it makes the execution times even more unpredictable.
This Commit contains a couple of changes to the anti-spam and an initial implementation of a "Serial commands" batch queue.
I have a couple of small issues with it.
The first part is that the serial commands addition is not applying to sufficient commands. Specifically, it should also apply to all drawing commands that use the
/markcommand (eg:/cuboid,/filletc) This would fix the long standing race issue with those commands.In addition, long running commands, such as
/replaceallwould likely be best to be run on this batch queue.Next, IMO, overloading of "Serial commands" with the double counting of the
/placecommand in the anti-spam is really not a good idea. I guess that the source problem that this is supposed to solve is that the/placecommand is one of the few commands where it's likely that there can be sufficient load to have the backgrounded commands overlapping to a large extent.For this issue (huge numbers of
/placecommands from multiple clients) I would suggest that the/placecommand is instead double counted by adding each run to theblock-spam-checkas well as the normal command spam check. This would fix the problem at source by removing the main advantage (Spam counters) for using it in parallel to normal setblock packets (/placeis still needed to place physics blocks, doors, though). This will also have lower layer advantage in that SetBlock packets are considerably smaller than place command containing Chat packets.Lastly, I feel that this change increases the need for a
/trustcommand for cmd-spam as it makes the execution times even more unpredictable.