# Why .NET Pure / VMA / SHARD is failed

The failed cell is specifically **dotnet-pure / VMA / SHARD**, not managed
.NET generally. Its kernel SHARD cell is qualified. VMA SINGLE, MONO and POOL
also have numeric observations; these do not qualify four-listener SHARD.

The retained full VMA run delivered all **1,920,000 measured requests** and
reported all 32 session stability checks passing, but successful Logon counts
were **32 / 0 / 0 / 0**. The parameter audit correctly rejected the three idle
listeners. The first warmup also shed 66,649 requests; that is retained separately
and is not the reason for the topology rejection. See the
[delivery and lifecycle evidence](dotnet-managed-vma-shard-participation-scan-20260910.json).

## What the code establishes

[`CreateListener` and `ServeSessionsSharded`](../../bench/dotnet/fixbench/libhft-net/Program.cs)
create four independent sockets on the same endpoint, set Linux `SO_REUSEPORT`
before bind, and give each socket its own pinned owner. The kernel control
recorded Logon counts 2 / 14 / 8 / 8. A missing reuse-port flag or absent worker
does not explain the VMA observation.

SCAN's startup logs identify VMA 9.8.80-1. In the matching upstream tag,
[`ring_slave.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/dev/ring_slave.cpp)
attaches same-tuple TCP listeners as sinks of an existing receive flow.
[`rfs_uc.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/dev/rfs_uc.cpp)
tries those sinks in order and stops when a sink retains the packet. The TCP
listener path in
[`sockinfo_tcp.cpp`](https://github.com/Mellanox/libvma/blob/0dc96e02cd226587c26767fe0350bda3f52f95b2/src/vma/sock/sockinfo_tcp.cpp)
can retain handshake/control packets. This is consistent with first-listener
admission, not kernel-style reuse-port distribution. The upstream TCP option
handler has no corresponding reuse-port group selection; UDP's reuse-port
handling is not a TCP remedy.

This is version-matched source evidence, not proof that the packaged binary is
unmodified, and not a packet trace identifying the exact dispatch of every SYN.
The [earlier vendor review](vma-9.8.80-source-review-20260910.md) records the same
limitation independently of this .NET Pure result.

## Fix boundary

No validated launcher-only fix is available from these checks. The prior JNI
[per-thread ring control](java-jni-vma-shard-ring20-diagnostic-20260910.json)
failed before Logon; it must not be called a fix for .NET Pure.

A pool, separate ports, kernel fallback, or accepting three idle listeners would
change the experiment. None is used to fill this cell. The existing rejection
and failed matrix row stay in place.

The next proposed investigation is a **bench-private VMA TCP reuse-port fix**,
not a replacement of `/usr/lib64/libvma.so.9`. It requires explicit scope approval,
then stable connection ownership across handshake retransmissions and listener
lifecycle, concurrency/error tests, offload and role-affinity evidence, and a fresh
full run proving all four listeners participate. A build or a balanced Logon
count alone is insufficient qualification. No vendor code or library has been
changed by this review.