docs: tighten comments to the non-obvious why

Cuts explanation that restated the code or repeated itself, and keeps the parts
a future change would otherwise undo.

The same fact was asserted in three places: BanChannel.IsExempt, BanExemptions
and LoginAllowlist each explained that an exemption withholds escalation only.
It now lives on the seam that defines it, and the other two point at it.

The seed short-read comment was eight lines arguing a decision; the load-bearing
part is that waiting costs a connection slot per one- or two-byte client, so
that is what it says now. The new test-collection markers are one line each
rather than a summary of how STArrayPool works internally.

Also drops a fully-qualified System.Func in BanExemptions in favour of a using.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kamron Batman 2026-07-30 18:40:02 -07:00
parent 65bdfe6cd7
commit b6c0a0bde8
No known key found for this signature in database
GPG key ID: 7D81DF26D9A5D94A
6 changed files with 17 additions and 33 deletions

View file

@ -696,14 +696,9 @@ public partial class NetState : IComparable<NetState>, IValueLinkListNode<NetSta
}
else
{
// Fewer than four bytes for a raw seed: disconnect rather than wait. This
// only affects pre-0xEF clients (0xEF goes through HandlePacket, which
// already waits for its 21 bytes), and waiting here would be paid for on
// the path that has to survive a flood -- a garbage client sending one or
// two bytes, or a slow loris dribbling a byte every few seconds, would
// hold a connection slot for the full ConnectingSocketIdleLimit instead of
// being dropped immediately. With a fixed MaxConnections table that trades
// capacity for a rare fragmentation case a reconnect already fixes.
// Disconnect rather than wait. Waiting would hold a connection slot for
// the full ConnectingSocketIdleLimit per one- or two-byte client, which
// is what a flood sends. Only pre-0xEF clients reach here.
Disconnect(string.Empty);
}
break;