Server client network stablize

[KT053374]

Summary

While testing on the Asheron4Fun live server, we encountered repeated outbound network failures during heavy multibox activity. The issue presented as System.ArgumentException failures originating from MessageFragment.CreateServerFragment() during Session.TickOutbound(), along with related fragment-state messages indicating invalid positions and incorrect remaining-data calculations.

Problem

Investigation identified that multiple client sessions could process the same GameMessage while sharing its underlying MemoryStream.

In simple terms, the old code allowed several sessions to read from the same message while also sharing one movable stream position. One session could move that position while another session was still reading, causing the second session to read from the wrong location. Under enough concurrency, fragment boundaries could become inconsistent and eventually result in out-of-range reads and the exceptions observed in the logs.

Fix

The outbound message is now serialized and frozen once into a byte buffer when it enters the network queue. Each session then creates its fragments from fixed, read-only slices of that frozen payload instead of moving a shared MemoryStream cursor.

This removes the shared mutable stream position entirely, so one session can no longer interfere with another session's fragment reads.

The change also corrects an edge case in TailSize where messages whose payload length was an exact multiple of the 448-byte fragment size could incorrectly report the final fragment as header-only.

This change does not alter the packet format, fragment size, message serialization format, or checksum algorithm. It only changes how the already-serialized outbound message data is accessed during fragmentation.

The implementation also removes the temporary per-fragment payload copy by allowing ServerPacketFragment to operate directly on the read-only message slice. The primary purpose of this change is correctness and thread safety, with reduced fragment-allocation churn as a secondary benefit.

Regression tests were added for both the concurrency scenario and the exact-multiple fragment-size case.

Validation

The targeted network tests pass 4/4 with 0 failures.

The patched build was deployed to the Asheron4Fun live server on October 6, 2026 at 15:59:12 and remained under live production traffic through the end of the attached logs on October 12, 2026 at 10:38:42.

During that period, the patched server processed exactly 134,834 new network sessions, including same-IP multibox activity reaching at least 13 concurrent sessions, with no recurrence of:

• MessageFragment.CreateServerFragment() exceptions
• Session.TickOutbound() fragmentation failures
• System.ArgumentException bounds errors
• There is no data remaining
• More data to send then data remaining!
• Passed index computes to invalid position size

The changes in this PR are currently live on Asheron4Fun. Anyone who would like to test the implementation is welcome to log in as a client and exercise the server under normal or multibox usage.

The attached server-log archive contains approximately 5 days and 18 hours of post-patch live-server activity. For reviewers wishing to compare behavior before and after deployment, ACE_Log.txt.4 contains both sides of the transition:

• Earlier in ACE_Log.txt.4, the original System.ArgumentException / MessageFragment.CreateServerFragment() failure is recorded repeatedly.
• The patched server restart occurs in that same file at 2026-10-06 15:59:12.
• Logs following that restart, continuing through ACE_Log.txt.3, .2, .1, and the current ACE_Log.txt, show the post-patch soak period with no recurrence of the original fragmentation failure.

The remaining rotated logs in the ZIP are retained as additional historical context.
ACE_Log.txt.zip