From 5f949a86e238fad8e5018aeba88deb483d773d9a Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Thu, 25 Jun 2026 11:34:34 -0400 Subject: [PATCH] =?UTF-8?q?docs(spike):=20event-session=20reuse=20spike=20?= =?UTF-8?q?results=20=E2=80=94=20GREEN?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v8 Event session reuses across SendEvent (~10-16x amortization); register-once sufficient; session survived 25s idle; event reads stay gated (C2). Live-validated against wonder-sql-vd03. Gate decision: GREEN -> HistorianGateway Stage B1 (separate event-session pool for SendEvent) warranted. Claude-Session: https://claude.ai/code/session_012SDSQ3AcaXqPcBtDESBRii --- .../event-session-reuse-spike-results.md | 111 ++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 docs/reverse-engineering/event-session-reuse-spike-results.md diff --git a/docs/reverse-engineering/event-session-reuse-spike-results.md b/docs/reverse-engineering/event-session-reuse-spike-results.md new file mode 100644 index 0000000..bdce09e --- /dev/null +++ b/docs/reverse-engineering/event-session-reuse-spike-results.md @@ -0,0 +1,111 @@ +# Event-session reuse spike — live results + +> **Question:** does the 2023 R2 historian honor REUSING one authenticated **v8 Event** +> session (ECDH `ExchangeKey` → RC4 token → `ConnectionType=Event`, then `RegisterCmEventTag`) +> across multiple `SendEvent` ops, instead of the per-op open+register the SDK does today? +> This is the precondition for amortizing the EVENT path (HistorianGateway `pending.md` A1 +> broadening, Stage B0 / B1). +> +> **Verdict: GREEN — a v8 Event session reuses across sends, register-once is sufficient, +> and the amortization is ~10–16×. Event READS stay gated (C2) and are not a reuse signal.** + +**Date:** 2026-06-25 +**Branch:** `feat/amortization-broadening` +**Server:** live 2023 R2 (`wonder-sql-vd03`), RemoteGrpc transport. +**Sandbox identity:** `HISTORIAN_EVENT_SANDBOX_TAG=HistGW.LiveTest.EventSpike` — the CM_EVENT send +buffer has **no per-tag routing field** (it registers against a fixed system tag), so the sandbox +value is stamped into the event `Type`/`SourceName`/`Namespace` + a `SpikeMarker` property as an +**identity marker**; no real tag is written or overwritten. +**Harness:** `tests/AVEVA.Historian.Client.Tests/EventSessionReuseSpikeTests.cs` driving the B0a +seams `HistorianGrpcEventWriteOrchestrator.OpenAndRegisterEventSession` (open v8 Event session + +`RegisterCmEventTag` ONCE) and `SendEventOnSession` (send only — no open/register). + +--- + +## 1. Send reuse — GREEN + +`ReusedEventSession_SendsTwice_SecondSkipsHandshake` **passed** (both runs): one +`OpenAndRegisterEventSession` then **two `SendEventOnSession` on the same v8 Event session** — both +accepted (`AddStreamValues` `BSuccess=true`). + +``` +open+register (ECDH handshake + RegisterCmEventTag) = 242 ms (run 1: 350 ms) +registration diag: RTag=True; EnsT=True +reused-send[0] = 23 ms, ok=True +reused-send[1] = 22 ms, ok=True +``` + +The server accepts the same v8 Event client handle across back-to-back sends. The session handle is +an immutable `readonly record struct (uint ClientHandle, Guid StorageSessionId)`; the send is +stateless on the client side (each call reserializes a fresh `"OS"` buffer), so nothing per-op is +baked into the handle. + +## 2. Amortization — ~10–16× + +The open+register (P-256 ECDH `ExchangeKey` → RC4 credential token → v8 `OpenConnection` → +`RegisterCmEventTag`) costs ~242–350 ms and is paid **once**; a reused send is ~22 ms. So over a +burst of N sends the per-send cost collapses from ~(265 ms open + 22 ms) to ~22 ms — a ~10–16× win +on the send path, same shape as the v6 read/write amortization (`handshake-reuse-spike-results.md`). + +## 3. Register-once is sufficient — GREEN + +`ReusedEventSession_RegisterOnce_ThenSendMany` **passed**: `RegisterCmEventTag` run **once** (inside +`OpenAndRegisterEventSession`), then **three** sends, all accepted. + +``` +register-once send[0] = 25 ms, ok=True +register-once send[1] = 22 ms, ok=True +register-once send[2] = 22 ms, ok=True +``` + +CM_EVENT registration is **session-scoped, not per-send** — the server holds the registration for the +session's lifetime. A reuse pool registers once per warm session, not per op. + +## 4. Idle tolerance — survived ≥25 s (best-effort, single sample) + +`ReusedEventSession_IdleSweep_BestEffort` (log-only): after a send, a **25 s idle gap**, then another +send — **the second send succeeded** (`session SURVIVED the idle gap`). Notable: the v6 read session +idle-expires at a ≥25 s gap (`handshake-reuse-spike-results.md` §3), but this v8 Event session +survived 25 s. This is a single-sample best-effort observation — a keepalive should still ping under +the ~20 s floor for safety margin until the v8 Event idle boundary is characterized more finely. + +## 5. Read-after-send — GATED (C2), not a reuse signal + +`ReusedEventSession_ServesReadAfterSend_BestEffort` (log-only, hard-bounded by a 5 s gRPC deadline + +an 8 s cancellation): the read-after-send on the same session **did not return data** — it cancels at +the bound: + +``` +read-after-send -> swallowed (RpcException Cancelled / OperationCanceled) + => read gated/unverified over gRPC (expected) +``` + +This matches the pre-existing C2 gate: event **reads** over gRPC long-poll `GetNext` to a no-data +terminal and are unverified. So the spike did **not** prove a one-session-serves-both-kinds property +for reads — `SendEvent` is the only trustworthy reuse signal. (An unbounded read hung the first run; +the harness now bounds it so the spike is a clean, re-runnable record.) + +--- + +## 6. Implications for Stage B1 (the event-pool build) + +GREEN → a **separate event-session pool** (the approved B1 approach) is warranted and high-value: + +1. **Amortize `SendEvent` through a bounded event-session pool.** Open+register a v8 Event session + once per warm session; lease it per send op (exclusive, like the v6 pool); reuse across a burst. + ~10–16× on the send path. +2. **Keep the event pool SEPARATE from the v6 pool** (B1, as approved) — different auth (ECDH/v8), + heavier re-handshake on drop, and its own idle characteristics. +3. **`ReadEvents` stays PER-CALL / gated (C2).** Reads are unverified over gRPC regardless of reuse, + so the event pool amortizes **sends only**; `ReadEvents` is unaffected by B1 and stays on the + per-call path. (This refines the design's "route SendEvent + ReadEvents through the pool": only + `SendEvent` is routed; `ReadEvents` remains per-call because it is gated, not because of reuse.) +4. **Keepalive:** ping the warm event session under the idle floor. The cheap keepalive op for the + event channel is TBD in B1 (the v6 pool uses `GetSystemParameter`; the event session's equivalent + warm-touch needs picking — likely a no-op send or a lightweight event-channel status op). +5. **Reactive re-auth:** on an expiry-looking failure, evict + full v8 re-handshake (heavier than the + v6 re-auth — one ECDH + register penalty). + +**Gate decision: GREEN → HistorianGateway A1 Stage B1 (a bounded `HistorianEventSessionPool` for +`SendEvent`, default-on, parallel to the v6 `HistorianSessionPool`) is warranted and earns its own +re-planned design + plan.**