Lands the design-contract pivot ahead of any cache implementation code so
reviewers can evaluate the change to the "purely transparent proxy" stance
independently of the Phase-11 code that depends on it.
- docs/design.md: rewrite "What this is" / Read-coalescing / Failure-modes
sections to acknowledge the opt-in cache; add new "Response cache (Phase
11)" section covering lookup order (cache -> coalesce -> backend), multi-
tag range TTL = min, post-rewriter storage, address-range-overlap write
invalidation, hot-reload PLC-wide flush, no-persistence, AllowLongTtl gate,
and LRU-bounded capacity. Extend log event table with mbproxy.cache.*
events. Extend per-PLC status field table with cacheHitCount /
cacheMissCount / cacheInvalidations / cacheEntryCount / cacheBytes.
Extend hot-reload propagation table with CacheTtlMs / Cache.* rows.
- docs/kpi.md: graduate Tier 1.8 (response cache) from "requires Phase 11"
to "shipped in Phase 11" and add Tier 2.4a cache-memory section.
- CLAUDE.md (mbproxy): update Purpose paragraph and the Architecture
headline bullets to reflect the transparent-by-default + opt-in-cache
contract; flip "Implementation complete through Phase 10" to "through
Phase 11".
- install/mbproxy.config.template.json: add a fully-commented Mbproxy.Cache
block and a CacheTtlMs example on a BcdTags.Global entry, with prominent
staleness commentary documenting the design contract.
No code changes in this commit - implementation lands in a follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When two or more upstream clients send the same FC03/FC04 read while a
matching request is already in flight on the same PLC's multiplexed
backend socket, attach the late arrivals to the existing InFlightRequest
.InterestedParties list instead of opening a second backend round-trip.
The single backend response fans out to every attached party with each
party's original MBAP TxId restored individually. Zero post-response
staleness — coalescing operates entirely within the in-flight window
(microseconds to ~10 ms typical); the proxy is NOT a cache layer.
Headline mechanism:
- New record struct CoalescingKey(UnitId, Fc, StartAddress, Qty) keys
the per-PLC InFlightByKeyMap. FC03 and FC04 are separate Modbus
tables and never share a key; different unit IDs never coalesce;
writes (FC06/FC16) bypass the coalescing path entirely.
- InFlightByKeyMap uses a simple lock around a Dictionary; atomic
TryAttachOrCreate either appends a new party to the in-flight
request's mutable List<InterestedParty> or invokes a factory to
build a fresh entry. Per-entry MaxParties cap (default 32) bounds
fan-out cost; past the cap, the next arrival opens a new entry.
- PlcMultiplexer.OnUpstreamFrameAsync takes the coalescing path for
FC03/FC04 when Mbproxy.Resilience.ReadCoalescing.Enabled. The
factory closure does the Phase-9 work (allocate TxId, add to
CorrelationMap); the channel send happens AFTER returning from
TryAttachOrCreate so the map lock is not held across the async send.
- Response fan-out in RunBackendReaderAsync removes the entry from
InFlightByKeyMap before iterating InterestedParties, ensuring no
concurrent attach can mutate the list during iteration.
- Cascade + watchdog paths also drain the key map so a stale entry
cannot outlive its backend round-trip.
Counter accounting balance (per snapshot): CoalescedHitCount +
CoalescedMissCount equals total FC03 + FC04 requests since startup.
Even with coalescing disabled, every read still bumps Miss so dashboard
math stays balanced.
New surface (additive only):
- src/Mbproxy/Proxy/Multiplexing/CoalescingKey.cs
- src/Mbproxy/Proxy/Multiplexing/InFlightByKeyMap.cs
- src/Mbproxy/Proxy/Multiplexing/CoalescingLogEvents.cs
- ReadCoalescingOptions on ResilienceOptions
- CoalescedHitCount / CoalescedMissCount /
CoalescedResponseToDeadUpstream counters surfaced on /status.json
per PLC and as a compact "Coal" cell on the HTML status page.
Phase 9 test patch: TwoUpstreams_ProxyTxIds_AreDistinct_OnTheWire
previously read the same register from both clients (which now
coalesces). Patched to read two different addresses so the test still
proves distinct backend TxIds without violating the coalescing
contract.
Tests added: 24 new (19 unit + 5 E2E):
- CoalescingKeyTests (5)
- InFlightByKeyMapTests (6, includes concurrent stress)
- ReadCoalescingTests (8, stub-backend with deterministic delay)
- ReadCoalescingE2ETests (5, pymodbus simulator; coalescing-active
during overlap is proven against the stub, not the sim, due to
pymodbus 3.13's known concurrent-frame bug)
Total: 325 tests passing (282 unit + 43 E2E).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Joseph Doherty