From ff58ad4f60f8be5cd2f762b791f5c7b0e107f13a Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Wed, 22 Jul 2026 06:49:39 -0400 Subject: [PATCH] =?UTF-8?q?docs(akka-msquic):=201.6=20status=20update=20?= =?UTF-8?q?=E2=80=94=20Artery-TCP=20implementation=20began=202026-07-03?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Corrects the same-day report: PR searches for 'quic' missed work named 'artery'. Artery is landing rapidly on upstream dev as Artery-TCP (openspec #8313; framing/handshake G1-G2; parallel lanes #8356/#8357; large-message streamId 3 #8352; MNTR/CI for both transports), with Serialization.V2 in parallel. TCP-first resolves §7's forward note: pipeline benefits arrive without libmsquic, dropping the §6 platform constraints from the 1.6 adoption path. No previews or public benchmarks yet. --- akka_msquic_transport.md | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/akka_msquic_transport.md b/akka_msquic_transport.md index 00c8ea8..ef095e7 100644 --- a/akka_msquic_transport.md +++ b/akka_msquic_transport.md @@ -41,6 +41,21 @@ recommendation at the end. So "wait for 1.6" is not a near-term plan. QUIC benefits this year would mean building it in-house. +> **STATUS UPDATE (2026-07-22, same day, deeper look):** the two paragraphs above are correct about +> *QUIC* but stale about *Artery* — searching PRs for "quic" missed work named "artery". +> **Artery implementation began 2026-07-03 and is landing rapidly on `dev`, as Artery-TCP** (the +> JVM-parallel move): design spec via openspec (#8313, "artery-tcp-remoting"), transport-substrate +> validation gate G0 (#8315), TCP framing + envelope codec G1 (#8319), handshake/association G2 +> (#8320), parallel inbound/outbound lanes (#8356/#8357, Jul 11), dedicated large-message stream +> streamId 3 (#8352, Jul 10), quarantine port in flight (#8416), MNTR/CI integration for both +> transports (#8373/#8413). 192/192 Artery specs passing as of #8352. In parallel, +> **Serialization.V2** (source-generated + MessagePack internals) is in heavy development — ~30 +> merged PRs with wire-format snapshot tests and an open cross-component integration proof suite +> (#8407). TCP-first also confirms §7's forward-looking note: the Artery benefits (lanes, +> large-message stream, control stream) are arriving **transport-agnostic over TCP** — no libmsquic +> required — with QUIC as a later substrate swap. No preview release or public benchmark numbers +> yet; see the 1.6-status section of the conversation record for the remaining-work list. + ## 2. What the projects run today Both ScadaBridge and OtOpcUa pin **Akka 1.5.62** and use the classic **`dot-netty.tcp`** transport, @@ -246,10 +261,12 @@ extra framing. Only interesting for exotic proxy/firewall traversal. Skip. QUIC implementation in .NET, and nothing else in the box provides independent streams. So "QUIC without libmsquic" is not on the table, on any .NET version. -Forward-looking note: if Akka.NET's 1.6 Artery ships QUIC-only, libmsquic becomes unavoidable *at -that point* — worth watching whether upstream adds a TCP mode (to11mtm explicitly advocated -transport pluggability for firewall-restricted environments in the #7466 design discussion, citing -the JVM's TCP Artery). +Forward-looking note — **resolved 2026-07-22**: upstream did exactly this. The Artery port that +began landing on `dev` in July 2026 is **Artery-TCP** (openspec #8313), so the pipeline benefits +arrive without libmsquic, and QUIC becomes a later optional substrate — the outcome to11mtm +advocated in the #7466 design discussion. This also removes the platform/ops constraints of §6 +from the 1.6 adoption path (TCP, no native deps, no UDP firewall changes) unless/until a QUIC +substrate is chosen deliberately. ## 8. Would it actually alleviate the gRPC?