# hp TLS handshake and read ownership review The Java TLS adapter could accept a handshake after its absolute time budget had expired. Three regressions reproduced the escape through positive socket writes, positive reads, and a delegated engine task. Those paths are fixed without changing ordinary application-data writes. A separate .NET completed-read ownership defect is confirmed but remains unfixed while the restructuring session claims its files. These are functional checks, not latency measurements or completed NIC coverage. ## Java handshake deadline `PureJavaSslChannel` previously checked expiry around zero-byte socket waits and before starting a control-record write. The write helper then used the remaining budget as a no-progress timeout, which positive writes reset. The handshake loop and its inner unwrap loop also lacked checks while progress continued. A delegated task could finish after expiry and lead directly to a successful return. The adapter now checks the absolute deadline between handshake operations, between unwrap attempts, before and after delegated tasks, and throughout control record writes. Application-data `writeFully` retains its original no-progress policy, and the explicit non-positive handshake timeout still disables expiry. Read-triggered post-handshake control records also retain their bounded write budget, now enforced across positive progress. No lock or allocation was added to the application-data path. The regressions use the actual adapter with finite scripted engine/socket work. The first operation deliberately takes 150 ms against a 100 ms budget, then returns positive progress or completes its task. All three deadline cases failed before the patch and passed afterward; the fourth case checks all three progress paths with expiry disabled. This is not a provider-task cancellation mechanism: a synchronous task cannot be preempted, but its over-budget completion is rejected. Handshake socket operations require the documented non-blocking channel contract. The broader run passed 53 tests in seven current classes with no failures, errors or skips: the channel tests, context factory, TLS settings, cross-provider TLS parity, native TLS loopback, concurrent native TLS configuration isolation, and required-native check. Its warmed idle TLS polling loop still allocated zero bytes across 10,000 polls. The live TLS allocation test reported 2,964 bytes per round trip against its unchanged 4,096-byte ceiling. These allocation observations are not latency or throughput improvements. ## .NET completed read result ownership `ManagedSession.Peer.ReceiveReadyTls` consumes a successful read's result but disconnects on fault or cancellation without consuming the completed `ValueTask`. In the [.NET 8 TLS implementation](https://github.com/dotnet/runtime/blob/v8.0.0/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.IO.cs), reads use a pooled async builder. Its [result implementation](https://github.com/dotnet/runtime/blob/v8.0.0/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/PoolingAsyncValueTaskMethodBuilderT.cs) returns the completed state to its cache from `GetResult`, including when the result throws. A status check alone does not perform that cleanup. A separate harness invokes the actual peer read method from the already-verified managed assembly. It uses a controlled `SslStream` read source and checks that one pending operation is retained and its completed result is consumed once. Four data/EOF cases passed; four synchronous/pending fault/cancellation cases failed because the result was consumed zero times. The existing disconnect disposition was correct. No quantified GC, memory or latency impact is claimed. The harness stays outside `engine/dotnet`; that tree remains claimed by the .NET restructuring session. A release request is recorded in `docs/WIP_AGENT_CLAIMS.md`. No .NET production or test source was edited for this reproduction. The source method is unchanged from `218d577a230177939651e652603ed2fa9cf5f7be`. The checked assembly SHA256 is: ```text Atrekes.Libhft.dll 08249452f796d30af03ee08438b3f7245ee849540a298b0fc386a6731c2f465f ``` ## Evidence and staging Evidence lives under `~/archive/libhft/tls-handshake-review-20261002/`, including the failing-before Java log, passing-after four-case XML report, broader Java reports, and the .NET reproduction harness and log. Builds remain under `~/build/codex-libhft-hp/libhft`; foreground tests use `host-cpu-slot` in `isol` mode and may overlap shared-core conformance work. The managed installation still contains the older libraries; the home staging helper has not been run as root. The earlier 59-input manifest was preserved as `managed-stage-before-java-handshake-review-218d577a2.sha256`, not reused while the Java runtime bundle is refreshed. Managed physical NIC testing remains separate. ## Published source validation The complete managed refresh at `d24cf1ebaa6af1ed90b229e8ccfb7728257c7dfa` passed 1,000 Java tests in 36 selected classes, with no failures, errors or skips. The .NET suite passed 1,601 of 1,604 tests. Its three skips were live bypass NIC opening, SBE multicast loopback, and the native two-worker pool broadcast case. That pool case passed separately with `LIBHFT_ACCEPTOR_THREADS=2`; the other two remain untested by this suite. The 13 smoke/build-helper test methods passed too. The separate .NET read-ownership diagnostic still failed its four fault/cancel cases against assembly SHA256 `ccc6ac58b7c5752f7d1639410d814c030c5b0ddb8a415b18eb7d97daa844fd21`. The refresh compiled JNI and hftnet with both NIC providers and OpenSSL enabled. These are profile-free functional builds, not a tuned latency matrix. The native artifact hashes are: ```text libhftjava.so 3abb4dcf1de5e3dcd6ae85cb9e8f9006cd473780ef4743c93d0178abf53ac3a6 libhftnet.so 8afce6ad5a42962eefe39e152ebac2c457cca52ffbac0235ac9a28cbdc4493ab ``` The log, JSON and all 36 XML reports are archived as `managed-refresh-d24cf1eba.*` and `java-managed-d24cf1eba/`. The verified 59-input staging manifest was then withdrawn and retained as `managed-stage-before-fast-range-review-d24cf1eba.sha256` after a separate FAST range reproduction confirmed defects in all four surfaces. The home helper must receive another verified manifest before installing anything.