Joseph Doherty
56eee3c563
Adds the mbproxy service end-to-end. Phases 00-08 implement the production-ready single-listener / 1:1-backend transparent Modbus TCP proxy with bidirectional BCD rewriting for the ~54-PLC DL205/DL260 fleet. Phase 9 replaces the connection layer with a single backend socket per PLC plus MBAP TxId rewriting, lifting the H2-ECOM100's 4-concurrent-client cap as an operational ceiling. Phase 9 additions of note: - PlcMultiplexer + UpstreamPipe + TxIdAllocator + CorrelationMap - InFlightRequest with IReadOnlyList<InterestedParty> (load-bearing for Phase 10 read coalescing — do not collapse to a single field) - Per-request watchdog: surfaces Modbus exception 0x0B to upstream on BackendRequestTimeoutMs, defending against lost responses, dead-PLC paths, and pymodbus 3.13.0's concurrent-multiplexed- request bug (its ServerRequestHandler.last_pdu state race) - Status DTO + HTML gain inFlight / maxInFlight / txIdWraps / disconnectCascades / queueDepth (Tier 1.6 in docs/kpi.md) Tests: 263 unit + 38 E2E. Multiplexer correctness under truly concurrent backend traffic is proved against a stub backend in PlcMultiplexerTests; MultiplexerE2ETests paces requests so pymodbus 3.13's single-PDU framer stays in known-good mode. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
20 lines
616 B
C#
20 lines
616 B
C#
namespace Mbproxy.Proxy;
|
|
|
|
/// <summary>
|
|
/// No-op PDU pipeline: passes every frame through byte-for-byte without rewriting.
|
|
/// Registered as the <see cref="IPduPipeline"/> singleton in Phase 03.
|
|
/// Phase 04 replaces this registration with BcdPduPipeline.
|
|
/// </summary>
|
|
internal sealed class NoopPduPipeline : IPduPipeline
|
|
{
|
|
public void Process(
|
|
MbapDirection direction,
|
|
ReadOnlySpan<byte> mbapHeader,
|
|
Span<byte> pdu,
|
|
PduContext context)
|
|
{
|
|
// Intentional no-op: bytes forwarded unmodified.
|
|
// Phase 04: replace this registration with BcdPduPipeline.
|
|
}
|
|
}
|