demo · v130

Worker Protocol Decoder

When you transfer an RTCDataChannel to a dedicated worker (Chrome 130), all binary message parsing happens off the main thread. This demo simulates a binary protocol (type byte + length + payload) being decoded in a worker, contrasting the old pattern where every message decode blocked the main thread with the new pattern where the channel is owned by the worker entirely.

Checking RTCDataChannel transferability…
Peer A
main thread
──
RTCDataChannel
transferable (130+)
──
Worker
decode here
──
Peer B (main)
receives decoded
5 msgs
0
Messages sent
0
Decoded (worker)
0 µs
Main-thread blocked
0 µs
Worker decode time
Main-thread path (old pattern)
Messages would be decoded here, blocking the main thread.
Worker path (Chrome 130 — transferred channel)
Decoded messages arrive here after off-thread processing.
Click "Send burst" to simulate RTCDataChannel messages through the worker decode pipeline.
// Chrome 130: transfer RTCDataChannel to a dedicated worker
const pc      = new RTCPeerConnection();
const channel = pc.createDataChannel('data', { ordered: true });
const worker  = new Worker('decoder-worker.js');

// Transfer the channel — main thread loses access
worker.postMessage({ type: 'attach', channel }, [channel]);

// Worker decodes binary protocol without touching main thread:
// decoder-worker.js:
self.onmessage = ({ data }) => {
  if (data.type !== 'attach') return;
  const ch = data.channel;         // ← owns the channel now

  ch.onmessage = ({ data: buf }) => {
    const view = new DataView(buf);
    const type = view.getUint8(0);
    const len  = view.getUint16(1, false);
    const body = new TextDecoder().decode(buf.slice(3, 3 + len));

    // Post decoded result back to main thread
    self.postMessage({ type, body });
  };
};

see also