C# port of DistrictServer (DistrictServerCSharp/): full reimplementation, status + verification

[eaxiumnet]

C# port of DistrictServer (DistrictServerCSharp/) — full reimplementation, status + verification

This issue documents a complete C# (.NET 8) reimplementation of DistrictServer.cpp (~14k lines → ~40 modular service files) that has been developed in parallel with the C++ tree. It is informational / a proposal for discussion — the C++ DistrictServer/ remains the protocol oracle and the rollback path.

What it is

A wire-identical port of the C++ district server, structured by responsibility (modern C# idioms, no global mutable state):

• Handshake/ — AUTH/USES/WELCOME/JOIN/ANS, channel-sequencing, binary NMT control
• WorldControl/ — world registration + character handoffs
• Core/ — reliable TX queue + retry/ACK, transport-state tracking, packet diagnostics
• Gri/, Streaming/, SpawnZone/ — GRI match-start, level-streaming plan, spawn-zone markers/selection
• Pawn/ — ACK-gated pawn bootstrap + possession, remote-pawn multiplayer + dead-peer lifecycle
• Packages/ — cooked-package net-index resolver (parses cooked .u packages directly)
• Controller/ — controller field decoding, customisation replicator request dispatch
• Protocol/, Bits/, Crypto/, Net/ — UE3 wire layer, bit primitives, XTEA/BTEA, UDP listener

Port status (drift-gated)

Tools/check_port_sync.py inventories every C++ function and asserts it has a C# home:

• DistrictServer.cpp: 175 functions — 175 mapped / 0 not-ported / 0 unmapped (complete)
• ApbUdp.cpp wire layer covered by a file map; the only intentionally-unported items are dead Unreal.cpp (not in the C++ build, zero callers) and 3 zero-caller raw-float helpers

Verification

• dotnet build -c Release — 0 warnings / 0 errors
• --selftest — byte-identical wire output vs the C++ self-test vectors
• --drive (two-player) — full join path: AUTH → WELCOME → JOIN → 371 spawn-zone → district-enter answer → pawn-open → all 8 ACK-gated possession stages, remote pawns on both viewers, and the customisation transfer driven to ClientNotifyTransferComplete
• --resolver-check — parses a real cooked APBGame.u and reproduces the live C++ net indices exactly (controller 12426, holdable 15985→47088, storage 25478→56581)
• Tools/check_port_sync.py (default + --all) and Tools/check_deploy_sync.py — both green

Deploy state

The C# port is currently the deployed live district server in the local stack (Social 6969 / Financial 6970 / Waterfront 6971, world control 2108; win-x64 apphost, sha 526e3d64…, boot 2026-08-17 13:31). It is not yet committed to git — the DistrictServerCSharp/ tree is untracked, so nothing here is a merge request yet.

What is NOT yet proven

• A live-client smoke test: the deployed C# port has not yet been validated end-to-end against the real 1.1 client (all current verification is in-process/simulated). This is the last open verification gap.

Proposed path to a PR (for discussion)

1. Commit DistrictServerCSharp/ (+ the Tools/check_port_sync.py / check_deploy_sync.py gates) to a feature branch on the fork with incremental, reviewable history.
2. Run a live-client smoke test against the deployed C# port and capture the milestones.
3. Open a PR with the full diff + verification summary, keeping the C++ tree as the oracle for review.

Happy to restructure, split into smaller PRs, or adjust the architecture based on maintainer feedback before anything is merged.

[eaxiumnet]

Opened as a draft: #16 (eaxiumnet:feature/csharp-districtserver-port → main), 7 commits, 42 files, +14,220 / −0. DistrictServer/ is untouched and stays the protocol oracle.

Against step 3 of this issue:

• Full diff — commits are bottom-up (scaffold → wire layer → core services → subsystems → drive harness → docs/tools → UDP listener), so any prefix is a coherent buildable subset if you'd rather take it in stages.
• Verification summary — run from a pristine git archive export of the branch tip into an empty directory, so nothing untracked can contribute: dotnet build -c Release 0 warnings / 0 errors, --selftest PASS, --drive PASS (registered at World Server → WELCOME → both account sequences → remote pawn opened in both directions → ClientNotifyTransferComplete). --resolver-check PASS separately in a tree with a real cooked APBGame.u, reproducing the live C++ net indices exactly (controller 12426, holdable 15985→47088, storage 25478→56581).
• Completeness is machine-checked, not asserted — Tools/check_port_sync.py reports DistrictServer.cpp 175/175 mapped, 0 not-ported; PORTING.md §7 lists the only intentional exclusions (dead Unreal.cpp, three zero-caller raw-float helpers).

The verification gap this issue names is still open. No live-client session has been run against the C# build. It is what my local stack currently deploys (Social/Financial/Waterfront, managed apphost), but every district log it has produced so far is from --drive — the only AUTH identities present are the harness accounts 0000000001/0000000002, never a real client account. That's why #16 is a draft rather than ready for review; the smoke test is what should flip it.

Three behavioural fixes found while porting are native to the C# code and land in the C++ oracle via #13, so the two implementations stay wire-identical: per-endpoint channel sequences, the possession gate keyed by client endpoint instead of account id (the old global account-id set was never cleared, so a reconnect's district-enter ASK was received but never answered and the client parked at "Entering district"), and registration reply framing.

Happy to restructure, split, or keep this on the fork indefinitely if a parallel implementation isn't wanted in-tree.