skip to content

In WebRTC, when would a browser game send player inputs over an RTCDataChannel rather than over a WebSocket to a server?

level: juniorimportance: must knowfreq 32%

answer

  1. one TCP stream versus SCTP messages
  2. per-channel order and retransmission choices
  3. signalling, ICE and DTLS before byte one
  4. who terminates the connection

basics

~20 s

Pick an RTCDataChannel when late inputs are worth dropping: it sends SCTP messages over DTLS and UDP, optionally unordered and partially reliable, often peer to peer. A WebSocket is one ordered, fully reliable TCP stream to a server, simpler to set up.

solid answer

~50 s

A WebSocket (RFC 6455) is message framing layered over one TCP connection that begins as an HTTP Upgrade, so every message arrives reliably and in order, and one lost segment holds back everything sent after it. An `RTCDataChannel` (RFC 8831) carries messages over SCTP inside DTLS over UDP, and each channel chooses `ordered` plus an optional `maxRetransmits` or `maxPacketLifeTime`, so inputs can go unordered with `maxRetransmits: 0` and never wait for a stale one. Channels usually run peer to peer, which removes a server hop, but they cost more to start: an offer/answer exchange over a signalling path the application provides, ICE checks, a DTLS handshake and an SCTP association, plus a TURN relay where direct UDP is blocked. A server-authoritative game must run that whole stack on the server. Choose the data channel when latency and loss tolerance dominate; choose the WebSocket for reliable, server-bound traffic.

go deeper

for a junior

Recall the transport under each: a WebSocket rides one TCP connection, a data channel rides SCTP over DTLS over UDP. Name one thing a data channel can do that a WebSocket cannot.

for a middle

Explain per-channel ordered and retransmission options, why TCP's single ordered stream delays later messages, and the setup steps a data channel needs before its first message.

for a senior

Weigh topology: peer to peer versus a server-authoritative design that must terminate ICE, DTLS and SCTP, TURN fallback on locked-down networks, and keeping a WebSocket for signalling and reliable traffic.

for a principal

Frame the choice as a product decision: which traffic tolerates loss, which networks your players sit behind, and whether you can operate a WebRTC-capable server tier rather than ordinary HTTP infrastructure.

## Two transports with different contracts A **WebSocket** (RFC 6455) starts as an HTTP Upgrade request and then frames messages over **one TCP connection**. TCP delivers a single ordered byte stream, so the protocol can only ever be *reliable and in order*: if one segment is lost, every message behind it waits for the retransmission. An **`RTCDataChannel`** (RFC 8831, exposed by the W3C WebRTC 1.0 API) sends **messages over SCTP, inside DTLS, over UDP**, on a path that ICE has selected. SCTP is message-oriented and offers several independent streams; each data channel is a pair of SCTP streams with the same stream identifier, and RFC 8831 is explicit that **ordering is preserved only among ordered messages on the same stream**. | Property | WebSocket | RTCDataChannel | |---|---|---| | Transport | TCP (plus TLS for `wss:`) | SCTP over DTLS over UDP (ICE-selected path) | | Order | always in order | per channel: `ordered` true or false | | Reliability | always reliable | reliable, or limited by `maxRetransmits` or `maxPacketLifeTime` | | Encryption | optional (`ws:` versus `wss:`) | mandatory: RFC 8827 says all data channels MUST be secured via DTLS | | Usual far end | a server | another peer, or a server that implements the WebRTC stack | | Setup | TCP handshake, TLS, HTTP Upgrade | offer/answer, ICE checks, DTLS handshake, SCTP association | RFC 8831 says the data channel's API was designed to **closely mirror the WebSocket API** — `send()`, an `onmessage` handler, `readyState`, `bufferedAmount` — which is why the two are so often compared. The similarity ends at the transport. ## What the data channel buys a game Player inputs and position snapshots go stale within one game tick. RFC 8831's own first use case is a real-time game sending position and object state over unreliable channels, and it notes that a retransmission limit of zero combined with unordered delivery gives a **UDP-like service**: each message is sent exactly once and delivered in the order received. - **No head-of-line wait** for unordered, partially reliable messages: a lost input is simply abandoned. - **Several channels on one association**: a reliable, ordered channel for chat or match events beside an unreliable one for inputs, without the loss on one stalling ordered delivery on the other. - **A direct path**: when ICE finds a peer-to-peer route, there is no server hop to add latency, and no server bandwidth to pay for. - **Encryption you cannot forget**: there is no unencrypted mode. ## What it costs to open one Before the first message, the browser has to: 1. Exchange an offer and an answer with the peer over a **signalling channel the application provides** — WebRTC does not define it, and an existing WebSocket is a common choice. 2. Gather candidates and run **ICE connectivity checks**; on networks that block UDP the call needs a **TURN relay**, which reintroduces a server hop and its cost. 3. Complete a **DTLS handshake**, then set up the **SCTP association**. A WebSocket needs a TCP handshake, a TLS handshake for `wss:` and one HTTP Upgrade exchange, and it crosses HTTP proxies and port-443-only firewalls far more easily. ## Peer to peer or to a server The data channel's latency advantage is largest **peer to peer**. Many games are **server-authoritative**: the server validates inputs and owns the state. A data channel to a server is possible, but only if the server implements ICE, DTLS and SCTP itself — the specifications allow it, and which server stacks do so is an implementation question. A WebSocket server, by contrast, is ordinary HTTP infrastructure. ## A decision rule - Inputs or snapshots that are **useless when late**, a peer-to-peer or WebRTC-capable server topology, and users on networks where UDP usually works: **data channel**, unordered with a retransmission or lifetime limit. - Traffic that must arrive **complete and in order** to a conventional server — lobby, accounts, chat history — or users behind strict proxies: **WebSocket**. - Many games use **both**: the WebSocket for signalling and lobby traffic, the data channel for gameplay once the peers are connected. - Whichever you pick, measure on real player networks: the share of sessions that need a relay decides how much of the peer-to-peer latency advantage survives.

  • Could the game open one reliable and one unreliable data channel on the same peer connection, and why would it?
    Yes. RFC 8831 requires multiple simultaneous channels, and its use cases put game positions on unreliable channels and critical state on reliable ones. All channels share one SCTP association and one DTLS connection, and later channels need no new offer/answer, so a second channel is cheap. Ordering is per SCTP stream, so a lost input never holds back ordered delivery on the events channel.
  • The game already holds a WebSocket to its matchmaking server; what is that WebSocket's job once peers use data channels?
    It usually becomes the signalling path. WebRTC leaves the transport for offers, answers and candidates to the application, and a socket that already reaches both players is the natural carrier. Gameplay moves to the data channel once it opens, while lobby, account and other server-bound traffic can stay on the WebSocket.

saying these in an interview costs you the question

  • A data channel is simply a WebSocket that runs peer to peer.
  • Data channels are raw UDP, so every message on them may be lost.
  • A WebSocket message can be marked unordered to skip a lost one.
  • Peers using data channels need no server of any kind.
  • Data channel encryption can be switched off to save CPU.