Add packet capturing to the connections and make the analyzer reusable

[sven-n]

Phase 1 of #895, on top of #896.

This is the infrastructure for the analyzer page: watching the decrypted traffic of a connection which is already handled by one of our servers, without an external proxy. Nothing uses it yet — the capture service and the page follow in the next phases.

The capture hook

All three server types create their connections through the same Listener, so one hook in Connection covers connect server, game server and chat server. Both directions are captured unencrypted: incoming packets are read after the decryptor, and Output writes into the encryptor, so it still sees plain text.

• IPacketCaptureSink gets the complete, decrypted data packets. Sinks are registered with IConnection.AddCaptureSink and removed with RemoveCaptureSink. They are kept in an ImmutableArray, updated with ImmutableInterlocked — so there is no lock, and iterating them per packet stays allocation free.
• As long as no sink is registered, a connection captures nothing, and it stops capturing again when the last sink is removed.
• The incoming packets arrive as complete packets already. The outgoing ones don't: a write to the pipe writer is not necessarily one packet, since a large message can be written in several chunks and several packets can be written before a flush. The written data is therefore copied into an own pipe, which is read by CapturedPacketReader — a PacketPipeReaderBase, like every other packet source of the network layer. The data is copied when it's advanced (before the target can recycle the buffer) and flushed to the capture when the connection flushes.
• A capture may only start or end at a packet boundary, otherwise the captured data would begin or end in the middle of a data packet. The ExtendedPipeWriter knows where those boundaries are, so it applies a requested change itself: when nothing is written to the target yet, or right after a flush.
• The capture never blocks or breaks the connection: its pipe has no writer backpressure, and a failing capture write is swallowed. When the captured data is malformed, the reader stops and detaches itself — the connection is unaffected, and a later AddCaptureSink starts a fresh capture.
• IConnection has an Id now, so a connection can be addressed from the admin panel and correlated in the logs.

Deviation from the plan in #895: it described a settable CaptureSink property plus a separate multiplexing sink. AddCaptureSink/RemoveCaptureSink with the immutable array inside the connection turned out nicer: attaching and detaching is thread-safe without bookkeeping on the caller's side.

About the one remaining lock: the sinks are lock-free, but the lifecycle of the capture (starting and stopping it) is guarded by a lock. It's only held for that rare operation, never on the path of a data packet. A lock-free variant of the lifecycle would have a small window in which a capture is started and immediately torn down by a concurrent removal, so this seemed like the better trade.

The analyzer

Three changes so it can serve more than the WinForms tool:

• The client version is a parameter of ExtractInformation / ExtractShortInformation instead of a property, so one instance can analyze connections with different client versions concurrently. It had to be threaded through the private extraction chain as well, because DetermineDynamicStructLength uses it to decide the item data size of the extended season 6 client.
• The definitions are selected by their Direction element and a PacketDefinitionSet, instead of "one file per direction". Every packet in every definition file has a Direction, so this is equivalent for the game server, and it's what makes the connect server and chat server definitions usable — those files contain both directions (and one Bidirectional packet). Both files are copied to the output now.
• The definition files are only watched for changes when requested. That's a development feature, so only the WinForms tool switches it on.

Tests

14 new tests for the capture (PacketCaptureTest) covering: a received packet, a sent packet, a packet written in two chunks, two packets in one write, a C2 packet with a two byte length, an incomplete trailing packet that is only reported once completed, several sinks and their removal, capturing being stopped and started again, an exception in a sink not breaking the connection, malformed data stopping the capture without breaking the connection, and — with and without a sink — that the written data still arrives at the target pipe unchanged.

6 new tests for the analyzer (PacketAnalyzerTest), guarding the refactoring: the same packet code resolving to InstantMoveRequest or ObjectMoved depending on the direction, AddNpcsToScope075 vs AddNpcsToScope depending on the client version passed per call, the connect server set resolving ServerListRequest, a game server packet not being found in the connect server set, and the Bidirectional chat ChatMessage being found in both directions.

They live in MUnique.OpenMU.Network.Tests, which now references the analyzer library — that also confirms the packet definition xml files flow transitively into a referencing project's output. Say the word if you'd rather have a separate test project for the analyzer.

Verification

• dotnet build MUnique.OpenMU.sln -p:ci=true → 0 errors; no warning originates in a file this PR adds or changes.
• The complete test suite passes: 1551 tests, 0 failures (MUnique.OpenMU.Network.Tests is at 51 passed, 4 skipped, up from 31 passed).
• The WinForms tool builds and its call sites are adapted; I can't run it here, so a quick smoke test of the tool would be good before merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Pb82LmoaUVdZtBtQs7xrtA

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	7a41fa2
Status:	✅  Deploy successful!
Preview URL:	https://6aa26b81.openmudocs.pages.dev
Branch Preview URL:	https://claude-network-packet-captur.openmudocs.pages.dev

View logs