Campaign N slice N3. Retail never acks per packet: SharedNet::EnqueuePak
@ 0x00543B10 is the binary's only AckSequence (0x4000) construction site,
gated at >= 2.0 s on ReceiverData::timeStamp_ (@ +0x10), armed at
connection birth by ReceiverData::Init @ 0x00548EF0, and arbitrated
NAK-xor-ack per sweep by ClientNet::ProcessConnection @ 0x00545450
(m_SeqIDsWeNAKed non-empty -> EnqueueNaks, else EnqueuePak;
SharedNet::EnqueueNaks @ 0x00543BD0 shares the SAME timestamp -
campaign landmine #7).
- New Transport/AckNakScheduler: owns the one shared timestamp; a
non-empty NAK set suppresses the ack (N4 emits RequestRetransmit in
that branch; in N3 it emits nothing - a documented transitional state,
safe for exactly one slice on loopback), else ONE cleartext exact-flags
AckSequence carrying the tracker's HighestIdReceived, header sequence
borrowed from HighestIdSent without incrementing, 4-byte LE body.
Flags are an EQUALITY, never an OR (landmine #5 - ACE's dedup
exemption NetworkSession.cs:342-343 and watermark-skip :474-476 both
require the exact value).
- ReliableTransport.Sweep pump order per FlowQueue::Empty @ 0x00548A20:
interval clock, NAK/ack arbitration, pending resends, prune. The sweep
already runs in Tick and both handshake pump loops (landmine #8), so
cumulative acks flow during the character-list/enter-world floods at
ACE's own ~2 s cadence.
- WorldSession: the Phase 4.9 per-packet reflex ack in ProcessDatagram
and SendAck are DELETED; the [net-tick] acks/s probe now reads
Stats.AcksSent; new internal TransportClockSource seam drives the
2.0 s gate on virtual time in the conformance suite.
- N1 Fable-review advisory retired (Time-stamp fold-in): fresh reliable
sends now stamp Header.Time = the current interval id, matching retail
FlowQueue::TransmitNewPackets @ 0x00547A60 (header build at
0x00547A84); resends already re-stamped. ACE never reads inbound
Header.Time, so the wire stays compatible.
Tests: 723 Core.Net (7 new) - gate cadence + watermark-at-emission,
flags-equality pin + model acceptance at the reused sequence without a
watermark advance, NAK suppression and resume after the gap clears, a
50-packet CreateObject flood collapsing to ONE ack, the quiet-session
keepalive property across a 120 s virtual horizon (the reflex ack's
keepalive role, replaced and proven against ACE's 60 s TimeoutDeadline),
the Time fold-in, and a full FakeAceTransport lifecycle with zero
CRC/state/duplicate drops. Full solution Release: 9,744 passed /
5 skipped / 0 failed. Connected world-lifecycle gate PASS (capped +
uncapped-reconnect, graceful exits, 0 failures); canonical nine-stop
route PASS (0 failures).
Campaign section 9 N3 row updated (complete; SHA recorded at N4
kickoff).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace timeout-polled in-world UDP receives with one cancellable caller-buffered socket operation. Transfer only right-sized pooled datagrams through the FIFO, return every ownership edge deterministically, and send caller spans without a transport copy while preserving handshake pacing and ACK order.
WorldSession.NetReceiveLoop wrapped its entire while loop in a single
try/catch, so ANY non-timeout SocketException permanently killed the
background receive thread: the catch block at the loop's end was empty
(misattributed the error to "socket closed during shutdown"), and the
finally called _inboundQueue.Writer.TryComplete(), which silently and
irrecoverably stopped all inbound processing for the rest of the
session — no log line, no recovery path, and LiveSessionHost.Reconnect
has zero production callers to notice.
The realistic trigger is a well-known Windows UdpClient quirk: an ICMP
"port unreachable" reply to an EARLIER Send (e.g. against a stale ACE
session that already tore down its socket) surfaces as a
WSAECONNRESET SocketException on this socket's NEXT, completely
unrelated Receive call. NetClient.Receive already swallows the
expected SocketError.TimedOut heartbeat case; anything else reaching
WorldSession was a real, transient, per-datagram error being treated
as session-fatal.
Three changes, root-cause not a band-aid:
- NetClient's constructor now disables SIO_UDP_CONNRESET reporting on
Windows, so a delayed ICMP error can't poison receives at all.
- NetReceiveLoop now catches SocketException PER ITERATION, logs it,
and continues polling instead of exiting. The existing clean-shutdown
paths (cancellation, ObjectDisposedException during Dispose) are
unchanged — only the non-timeout-socket-error case that used to kill
the loop is now recoverable.
- NetClient.Receive no longer calls the ReceiveTimeout setter (a
setsockopt syscall) on every single call — only when the requested
timeout differs from the last-applied value, cached in a new field.
This was an unrelated but adjacent finding (4x/sec syscall churn at
the 250ms heartbeat cadence) in the same audit.
No change to outbound wire behavior, ack cadence, heartbeat interval,
or datagram ordering — this is purely receive-loop resilience.
Tests: NetClientTests gained a SIO_UDP_CONNRESET construction smoke
test and two ReceiveTimeout-caching tests. A new
WorldSessionNetReceiveLoopResilienceTests drives the actual private
NetReceiveLoop method (via the existing internal
IWorldSessionTransport seam + reflection) with a scripted transport
that throws a non-timeout SocketException on the first call, proving
the loop survives it and keeps enqueueing subsequent datagrams — fully
deterministic, no real sockets. Full solution suite green: 3204/3206
Core, 3462/3465 App, 552/552 Core.Net (skips pre-existing).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit c72ce028a927e15b8a54a86bbd0661a723dc84ca)
