v155 · network · webtransport

WebTransport Datagram writable streams and prioritization

The original datagram API gave every message one door: the single transport.datagrams.writable. Chrome 155 adds datagrams.createWritable(), which mints independent WebTransportDatagramsWritable streams — each with mutable sendGroup and sendOrder attributes — so urgent game input and bulk telemetry stop sharing one FIFO queue.

concepts

  1. createWritable, probed and called

    Check the exact new members on the real prototypes, then actually call createWritable() on a connecting transport and inspect what comes back: a WritableStream subclass carrying sendGroup: null and sendOrder: 0 defaults — next to an honest read of the legacy single-writable surface this build may still have.

  2. Priority lanes

    The product shape: an "urgent" writable and a "bulk" writable over one connection, options round-tripped for real, sendOrder raised mid-flight, real datagram writes queued against the connecting transport — or, on a build without the API, the same traffic pushed honestly through the one legacy door to show exactly what is missing.

  3. The write rules at the edges

    Three normative rules, executed: a non-BufferSource write must reject with TypeError; a datagram larger than maxDatagramSize must be silently discarded (the promise resolves!); and createWritable must reject a sendGroup from a different transport.

why it shipped

With one writable stream, every datagram waits behind every other datagram: a position update queued after a chunk of bulk state sync goes out after it, FIFO, no exceptions. Games, remote-desktop systems, and real-time media need classes of traffic — "send this now" versus "send this when idle". Multiple writables give each class its own queue, sendOrder ranks the queues (higher drains first among queued data in the same group), and FIFO still holds within each writable, so no class reorders its own messages. The same WebTransportSendOptions vocabulary drives stream prioritization, making datagrams and streams schedulable together. Chromium currently applies this ordering among datagram writables, and the API also reports the negotiated maxDatagramSize and discards oversized writes as the spec requires. The old single datagrams.writable remains in Chromium for compatibility — the spec itself has dropped it in favour of createWritable().

the API

const dg = transport.datagrams;              // WebTransportDatagramDuplexStream

const urgent = dg.createWritable({ sendOrder: 10 });
const bulk   = dg.createWritable({ sendOrder: 1 });
// both are WebTransportDatagramsWritable extends WritableStream

urgent.getWriter().write(inputDelta);        // drains ahead of bulk's queue…
bulk.getWriter().write(telemetryChunk);      // …but bulk stays FIFO internally

bulk.sendOrder = 20;                         // mutable: promote mid-session
dg.maxDatagramSize;                          // negotiated payload ceiling

references