dohertj2/scadaproj
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(akka-msquic): 1.6 status update — Artery-TCP implementation began 2026-07-03

Browse Source 
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.
This commit is contained in:
Joseph Doherty
2026-07-22 06:49:39 -04:00
parent dbfd5e7a7e
commit ff58ad4f60
1 changed files with 21 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
akka_msquic_transport.md
+21 -4
View File
@@ -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?