Prompt and context
A single WebTransport session must send live previews, control messages, and large files. Previews need low latency, control messages must arrive promptly, and files may yield bandwidth. Use WebTransportSendGroup, sendOrder, and getStats() to design the sending policy, including priority boundaries, congestion, reconnects, unsupported browsers, and errors.
MDN describes a send group as a set of streams and datagrams whose relative sending priority is determined by sendOrder; bandwidth allocation across different groups is implementation-defined. The interface remains experimental. This article synthesizes public material and does not claim to be a company-specific interview question.
What the interviewer is testing
The interviewer wants to see whether you distinguish relative ordering inside a group from fairness across groups, map business priority to observable queues, and explain the difference between unreliable datagrams and reliable ordered streams. A strong answer mentions createSendGroup(), passing sendGroup when creating a stream, sendOrder, group-level getStats(), congestion control, and capability detection; a weak answer merely says to “weight important messages.”
Questions to clarify first
- Which data may be dropped, and which must be reliable, ordered, and durable?
- What are the latency target, file-throughput target, and maximum queue age?
- Is priority fixed for the session or changed by user actions?
- Do target browsers support send groups, and can the fallback express the same business semantics?
A 30-second answer
“I would separate reliable control messages, lossy real-time previews, and background file transfer into explicit members. Members that need relative ordering share a send group, with sendOrder putting control and previews ahead of files; this is not a cross-group bandwidth guarantee. The sender bounds queues and item size, observes queueing and completion through getStats(), drops stale previews, and pauses files under congestion. If unsupported, it falls back to a separate connection or application scheduler while preserving control-message reliability.”
Step-by-step solution
Start with reliability boundaries. Use reliable streams for control, authorization, and final confirmation; datagrams can carry disposable live previews; reliable streams can carry files at low priority. A send group solves relative sending order among members. It does not turn different groups into predictable weighted queues or perform business retries.
After creating a group, associate sending streams or a writable datagram stream with it and set sendOrder on members. Document the numeric relationship in the protocol so implementations do not disagree about whether a larger or smaller value wins. Only members participating in strict ordering within the same group are compared; an unset order is implementation-defined.
const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
sendGroup: group,
sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 1,
});The application still needs budgets: bound preview datagram size and age, and coalesce the newest state for each object; file chunks need cancellation, retry, and checkpoint records. When queues approach their limits, drop stale previews first and pause files, but retain control messages. Use acknowledgements and idempotency keys for critical messages; a high send order does not imply delivery.
Congestion control is a transport preference, not a strict business SLA. congestionControl can express a low-latency or high-throughput preference, but the outcome depends on implementation and network conditions. Choose the preference when creating the connection, then use application metrics to reduce preview frequency or pause background work; do not claim a latency guarantee from one option.
Use the group’s getStats() and member-level metrics to observe queueing, sending, drops, retries, and completion latency. Record dimensions for group, message type, network, and session version, distinguishing “not sent yet,” “datagram lost,” and “receiver slow.” On reconnect, create a new group, restore reliable-stream state, and rebuild disposable previews from an authoritative snapshot instead of reusing stale stream objects.
Detect capability before opening the session. If send groups are unavailable, the core control stream must still work; use a separate reliable connection or an application queue. Do not block login, authorization, or submission to preserve a visual preview. Before shipping an experimental interface, provide browser cohorts, a rollout switch, and a kill path.
Example of a strong answer
I would split control messages, live previews, and file transfer into separate sending members, choosing streams or datagrams according to reliability. Members needing relative order share one send group: control gets the highest sendOrder, previews the next, and files the lowest; members without an order are outside strict comparison. Group order is relative, and fairness across groups is implementation-defined, so I would not present it as a bandwidth quota.
The application owns budgets, cancellation, idempotency, and expiry: under congestion it coalesces or drops old previews and pauses files, while control messages retain reliable acknowledgement. congestionControl expresses a preference, and getStats() measures queueing and completion latency. Reconnects rebuild the group and restore from a snapshot. Unsupported browsers keep the reliable control path and degrade or disable previews. I would monitor drops, latency, and task success by group and message type.
Common mistakes
- Symptom → Treat
sendOrderas a cross-group bandwidth weight; why it fails → The API defines relative sending order within a group; fix → Schedule across groups in the application and measure the result. - Symptom → Replace reliable acknowledgement with high priority; why it fails → Sending order does not guarantee delivery; fix → Use reliable streams, acknowledgements, and idempotency for critical messages.
- Symptom → Keep queuing every preview and file during congestion; why it fails → Latency and memory become unbounded; fix → Set budgets, coalesce latest state, and pause background transfer.
- Symptom → Reuse old stream objects after reconnect; why it fails → They belong to an expired session; fix → Rebuild the group, restore authoritative state, and resubscribe.
- Symptom → Make an experimental API the only channel; why it fails → Browser differences block core actions; fix → Detect capability, roll out gradually, and preserve a reliable fallback.
Follow-up questions and answers
What is the difference between group and cross-group priority?
Within one send group, participating streams or datagrams are compared by sendOrder; different groups are expected to receive fair treatment, but the exact split is implementation-defined. For cross-group weights, schedule queues or separate connections in the application and validate with metrics.
Why is a high send order not enough to protect previews?
Priority changes queue order; it does not change datagram unreliability or guarantee receiver processing. Previews still need expiry, coalescing, and drop rules. Control facts need reliable transport, acknowledgement, and durability.
How do you know pausing files helped?
Track file queue length, preview latency, control completion latency, and task success. Continue if control latency improves while previews meet their target; resume files within a budget when the network or business priority changes, avoiding indefinite starvation.
What is the fallback when send groups are unsupported?
Preserve the reliable control stream and core navigation first. Route previews through a separate data path, reliable stream, or no preview. Keep the same message protocol and cancellation rules so authorization, submission, and error semantics remain intact.