cf15beab76
Two fixes to the pending queue. A queued job whose client has gone was still costing a full ~9 ms verify for a verdict nobody would receive. It is now dropped at dequeue, which reclaims the slot immediately -- and that matters most during the reconnect rush that builds a queue in the first place. Running only ever transitions true to false, so reading it off-thread can waste a hash but can never skip a live connection. The 128 cap was a second, far tighter bound on something the engine already bounds. AccountLogin rejects a duplicate 0x80 via SentFirstPacket, so a connection holds at most one pending verify, and concurrent connections are capped at 4096. The cap now matches that, making it a backstop against the one-per-connection invariant breaking rather than a policy that fires first on real players -- an 800-client boot rush was eight times over the old limit. It was never a flood defence and no longer claims to be. A cap low enough to blunt an attack rejects legitimate logins for its duration, which is the denial of service arriving by another route; a cap high enough to avoid that blunts nothing. That belongs at the connection layer, where IP bans and the accept gate stop an attacker before he costs a hash. |
||
|---|---|---|
| .. | ||
| Application | ||
| BuildTool | ||
| Logger | ||
| Server | ||
| Server.Tests | ||
| UOContent | ||
| UOContent.Tests | ||