skip to content

In WebRTC's RTCDataChannelInit, what do ordered, maxRetransmits and maxPacketLifeTime control, and why may only one limit be set?

level: middleimportance: must knowfreq 24%

answer

  1. order versus delivery guarantee
  2. a count or a clock
  3. TypeError when both are present
  4. one channel type, one reliability parameter

basics

~20 s

The ordered option chooses send-order or arrival-order delivery; maxRetransmits caps how often a lost message is resent, and maxPacketLifeTime caps how many milliseconds it may be sent or resent. Neither gives a reliable channel; both throws a TypeError.

solid answer

~40 s

Each `RTCDataChannel` maps onto SCTP partial reliability: RFC 8831 requires RFC 3758's timed policy and RFC 7496's limited-retransmission policy. `ordered` (default `true`) decides whether the receiver releases messages in send order or as they arrive. `maxRetransmits` abandons a message after that many retransmissions; `maxPacketLifeTime` abandons it once that many milliseconds have passed since it was handed to the stack, first transmission included. With neither, the channel is fully reliable. Both answer one question — when to give up on a message — and DCEP's `DATA_CHANNEL_OPEN` (RFC 8832) carries one channel type and one 32-bit reliability parameter that is either a count or a lifetime, so the W3C API throws a `TypeError` if both are set. For position snapshots, `ordered: false` with `maxRetransmits: 0` sends each message once, delivered as it arrives.

go deeper

for a junior

Recall that a data channel is reliable and ordered by default, and that maxRetransmits or maxPacketLifeTime makes it partially reliable.

for a middle

Explain the two independent axes, what each limit counts, when the lifetime clock starts, and why setting both limits throws a TypeError.

for a senior

Match the mode to the data: a lifetime for snapshots that expire on a clock, unordered delivery to remove head-of-line waits, a separate reliable channel for events that must arrive.

for a principal

Treat reliability as a per-message-class contract across the product, deciding which classes may be lost and documenting the channel layout so every client and server agrees on it.

## Two independent axes A WebRTC data channel makes two separate promises, and `RTCDataChannelInit` sets each one: - **Order** — `ordered` (a boolean, default `true`). When true, the receiver hands messages to the application in the order they were sent. When false, each message is released as soon as it arrives. - **Reliability** — at most one of `maxRetransmits` or `maxPacketLifeTime` (both `unsigned short`). Setting neither gives a **reliable** channel: SCTP retransmits until the message is delivered or the association fails. The two axes combine freely, which is why DCEP (RFC 8832) defines six channel types: reliable, reliable unordered, and the two partially reliable policies, each ordered or unordered. | Settings | DCEP channel type | Behaviour | |---|---|---| | defaults | `DATA_CHANNEL_RELIABLE` | every message, in send order | | `ordered: false` | `DATA_CHANNEL_RELIABLE_UNORDERED` | every message, in arrival order | | `maxRetransmits: n` | `DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT` | at most n retransmissions, in order | | `ordered: false`, `maxRetransmits: n` | `DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED` | at most n retransmissions, arrival order | | `maxPacketLifeTime: ms` | `DATA_CHANNEL_PARTIAL_RELIABLE_TIMED` | sent or resent only within the lifetime, in order | | `ordered: false`, `maxPacketLifeTime: ms` | `DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED` | lifetime-bounded, arrival order | ## The two limits **`maxRetransmits`** counts attempts. The W3C specification says it "limits the number of times a channel will retransmit data if not successfully delivered". With `0`, a message is transmitted once and never again; RFC 8831 notes that zero retransmissions combined with unordered delivery gives a **UDP-like service** in which each message is sent exactly once and delivered in the order received. **`maxPacketLifeTime`** is a clock in milliseconds. It limits the time during which the channel will transmit or retransmit a message, and RFC 8832 says the lifetime **starts when the message is provided to the protocol stack** — not at the first retransmission. A message still queued behind others when its lifetime runs out may never be transmitted at all. Both values are clamped: if one exceeds the maximum the user agent supports, the W3C algorithm sets it to that maximum. ## Why only one limit The two limits are two policies for the same decision — when to abandon a message — and the protocol carries only one: 1. The in-band open message, `DATA_CHANNEL_OPEN`, has a single **Channel Type** byte and a single 4-byte **Reliability Parameter**, which holds the retransmission count for the `REXMIT` types or the lifetime in milliseconds for the `TIMED` types. 2. The W3C `createDataChannel` algorithm therefore checks the options up front: if both `maxPacketLifeTime` and `maxRetransmits` are set, it **throws a `TypeError`** and no channel is created. Choose the limit that matches what makes the data worthless. A position update superseded every 50 ms is worthless after a tick whatever the round-trip time, so a lifetime states that deadline directly; a retransmission count behaves very differently on a 20 ms path and a 300 ms path. ## Order and partial reliability together `ordered: true` with a limit still has a bounded wait: the receiver cannot release a later message ahead of an earlier one the sender is still retrying, so later messages wait until the earlier one is delivered or abandoned. The limit **bounds** that head-of-line delay; `ordered: false` **removes** it. One more rule from RFC 8832: before the peer's `DATA_CHANNEL_ACK` (or any other message) arrives, user messages on an in-band channel MUST be sent ordered even if the channel is unordered. ## Choosing a mode - **Inputs and position snapshots**: `ordered: false` with `maxRetransmits: 0`, or a `maxPacketLifeTime` close to the update interval. - **Chat, match events, file chunks**: the defaults — reliable and ordered. - **Independent commands that must all arrive but may arrive in any order**: `ordered: false` with no limit. - **Short-lived hints such as a cursor position or a typing indicator**: a lifetime limit, ordered or not as the receiver needs. ## Fixed for the channel's life The W3C specification states that a channel's properties **cannot change after it has been created**; `ordered`, `maxRetransmits` and `maxPacketLifeTime` are read-only attributes on the channel. To change mode, open another channel. That is cheap: all channels of a peer connection share one SCTP association, so a typical game runs a reliable ordered channel for events beside an unordered, partially reliable one for state.

  • When would you choose maxPacketLifeTime over maxRetransmits for game state?
    When the data's value expires on a clock, not after a number of attempts. A position snapshot replaced every 50 ms is useless after about one tick, whatever the round-trip time, and a lifetime states that directly. A retransmission count gives very different deadlines on a short path and a long one, so it suits a crude bound when the timing does not matter much.
  • With ordered true and maxRetransmits 2, can a later message still wait behind a lost one?
    Yes, for a bounded time. In-order delivery means the receiver cannot release a later message before an earlier one the sender is still retrying. Once the sender abandons the lost message after its two retransmissions, the later messages are released. Partial reliability bounds the head-of-line wait; setting ordered to false removes it.
  • Can an application switch an open data channel from reliable to partially reliable?
    No. The W3C specification says a channel's properties cannot change after creation, and its reliability attributes are read-only. The application opens a second channel with the new options and moves traffic to it; later channels share the existing SCTP association and need no new offer/answer.

maxPacketLifeTime is a courier told to bin a parcel if it cannot be delivered by noon, and maxRetransmits is a courier told to try three times; a parcel label in this system has room for only one of those instructions.

saying these in an interview costs you the question

  • Set maxRetransmits and maxPacketLifeTime together for a tighter bound.
  • Setting ordered to false on its own makes the channel unreliable.
  • maxRetransmits of 0 means the channel retries without limit.
  • maxPacketLifeTime starts counting at the first retransmission.
  • A partially reliable channel still delivers every message eventually.