-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(Core/Server): Improvements to antidos opcode handling #21502
Conversation
@skelUA Try this |
|
https://gist.github.com/Nyeriah/c2fe3652e36cf315f8b721f939c5d698 CMSG_CONTACT_LIST seems to be haywire, flagging many players per sec, I moved the policy from kick to warn to observe it so its spamming a lot as the logs show (very high packet counts per player, e.g over 700, while the policy expects 200 max) Edit: player reported kicks after loading screen finishes |
@Nyeriah That's strange, is that the only problematic opcode? And it affects more than a couple different accounts? I'll check tonight if there's any strange logic flaws. 800 packets of CMSG_CONTACT_LIST per second would be pretty crazy. I'm glad the individual customization provided helpful though in this particular case! haha. |
Yep, no logs from other opcodes so far, but sitting on over 50k lines of this one, from multiple accounts. The vast majority of them with no character (entering world I assume), with rare exceptions |
Couple changes to antidos opcode handling:
Implementation note: BlockingThrottle isn't an ideal solution as it temporarily prevents processing of remaining packets in queue (hence the name "blocking") and as such should only be used in careful and very specific cases. In an ideal world we'd have multiple packet processing queues with different properties however that would be a much more involved change. I can attest from experience that using a simple queue block to throttle AH searches works sufficiently enough without noticeable effects.
Changes Proposed:
This PR proposes changes to:
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.