v158 · webtransport · concurrency hints

Allowance tuner

Pick the concurrency you would tell the browser to expect, construct a real WebTransport with those hints, and read back what the object stored — then raise the hint on the live object through the read-write attributes. Nothing here is mocked: every value in the readback table came from the real accessor.

Enabled by default in Chrome 158. On an earlier build, run Chrome with --enable-blink-features=WebTransportAnticipatedConcurrentIncomingStreams, or flip chrome://flags/#enable-experimental-web-platform-features and relaunch. The connection target is a dead local port — the point is the hint plumbing, which happens before any packet leaves.

1 · Construct with hints

0–65535, or leave empty for no hint
0–65535, or leave empty for no hint
What the instance reports back
accessorreturned
…IncomingUnidirectionalStreams—
…IncomingBidirectionalStreams—
No object constructed yet.

2 · Raise the hint on the live object

The attributes are read-write so an application whose fan-out grows mid-session can widen the allowance without reconnecting. This doubles the unidirectional hint on the object constructed above and reads it back.

Construct an object first.

code path

const transport = new WebTransport("https://127.0.0.1:44443/never", {
  anticipatedConcurrentIncomingUnidirectionalStreams: 400,
  anticipatedConcurrentIncomingBidirectionalStreams: 50,
});
transport.ready.catch(() => {});   // dead port; claim the rejection
transport.closed.catch(() => {});

// Read back what was stored (null on a build that ignores the member):
transport.anticipatedConcurrentIncomingUnidirectionalStreams;  // → 400

// Raise it mid-object — the attribute is read-write:
transport.anticipatedConcurrentIncomingUnidirectionalStreams = 800;

The hint is advisory. The browser never advertises less than the spec's floor of 100 streams of each type, so a hint of 12 does not shrink the allowance — it simply records that 12 is all you expect.

see also