Skip to content

transport: plumb MaxIncomingStreams/MaxIncomingUniStreams to the shim config#74

Merged
ch4r10t33r merged 1 commit into
mainfrom
feat/stream-limit-config-65
Jul 3, 2026
Merged

transport: plumb MaxIncomingStreams/MaxIncomingUniStreams to the shim config#74
ch4r10t33r merged 1 commit into
mainfrom
feat/stream-limit-config-65

Conversation

@ch4r10t33r

Copy link
Copy Markdown
Collaborator

Closes #65.

EthEcQuicConfig declared max_incoming_streams / max_incoming_uni_streams (16384, with a passing defaults test) but toQuicConfig never read them — the one knob Go explicitly tunes for scale (sim/host.go defaultQuicConfig) was silently discarded.

What changed

  • Added max_incoming_streams / max_incoming_uni_streams to the shim QuicConfig (zquic_quic_shim.zig).
  • toQuicConfig now carries config.max_incoming_streams / …uni_streams into it, so the values are no longer dropped.
  • Test asserts a custom limit propagates through toQuicConfig into QuicConfig.

Honest scope note (the remaining hop)

The values now reach the shim but cannot yet be advertised on the wire: zquic 1.7.66's io.ServerConfig exposes no numeric incoming-stream limit — only transport_params_preset, whose default advertises initial_max_streams_{bidi,uni} = 1000 (and libp2p advertises 256 bidi / 0 uni). Honoring a custom value (e.g. 16384) needs a new zquic ServerConfig field. The shim documents this at the io.ServerConfig build site as an upstream follow-up.

This directly fixes the "silently discarded" bug the issue names, and scopes the zquic-side work transparently.

Verified on stock Zig 0.16.0: zig fmt --check, zig build test, zig build test-quic. README updated.

… config

`EthEcQuicConfig` declared `max_incoming_streams` / `max_incoming_uni_streams`
(16384) but `toQuicConfig` never read them, so the one knob Go tunes for
scale (`sim/host.go` `defaultQuicConfig`) was silently discarded. This adds
both fields to the shim `QuicConfig` and carries them through `toQuicConfig`,
with a test asserting they are no longer dropped.

The final hop — advertising a custom `initial_max_streams_{bidi,uni}` on the
wire — is not yet possible: zquic 1.7.66's `io.ServerConfig` exposes no
numeric incoming-stream limit (only `transport_params_preset`, whose
`default` advertises 1000). Honoring a custom value needs a zquic
`ServerConfig` field; the shim documents this at the `io.ServerConfig`
build site as an upstream follow-up.

Closes #65.
@ch4r10t33r ch4r10t33r merged commit 035d2e3 into main Jul 3, 2026
7 checks passed
@ch4r10t33r ch4r10t33r deleted the feat/stream-limit-config-65 branch July 3, 2026 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

transport: plumb MaxIncomingStreams/MaxIncomingUniStreams config to zquic

1 participant