Builder · Lesson 22

How does real-time communication keep information fresh?

Real-time communication prioritizes fresh state, timely interaction, audio, video, or events over waiting for a complete batch of data.

The real-time constraint

Fresh information is often more valuable than perfect history.

Real-time communication keeps participants informed while an event is happening. A video call, multiplayer game, live control loop, collaborative cursor, market feed, or notification stream may prefer a recent update over an old update delivered perfectly several seconds later.

Real-time does not mean zero latency. It means the system chooses deadlines and freshness targets that fit the interaction. The acceptable delay for a chat message is different from the acceptable delay for voice, video, motion control, or a live game.

Measure freshness against the user experience.A delayed message can still be correct, while a late voice packet may be useless. The protocol and recovery strategy must match the information being carried.

Choose the transport

Different real-time exchanges need different delivery guarantees.

01

WebSocket

A long-lived, bidirectional connection for ordered application messages, events, dashboards, and collaborative state.

02

WebRTC

A browser-oriented framework for peer connections carrying interactive media and data, often with UDP-based paths.

03

HTTP streaming

A server-to-client approach useful when the client mainly receives a stream and request-response remains convenient.

04

Datagrams

A low-overhead delivery choice when the application can tolerate loss, reorder updates, or recover at its own level.

TCP provides reliable ordered bytes but may delay later data while recovering a lost segment. Real-time applications sometimes choose a transport or codec strategy that allows fresh data to continue even when an old update is missing.

Connect the endpoints

WebRTC separates connection setup from the media or data path.

WebRTC lets browsers establish peer connections for audio, video, or data. It uses signaling to exchange descriptions and candidates, then negotiates a path and security parameters. Signaling is an application responsibility; WebRTC does not prescribe one single signaling server or message format.

01

Offer

One endpoint describes the media tracks, data channels, codecs, and capabilities it can use.

02

Answer

The other endpoint selects compatible capabilities and returns its own session description.

03

Candidate

Each endpoint advertises possible network paths, including local, reflexive, and relay candidates.

04

Secure path

The endpoints authenticate and encrypt the negotiated media or data exchange.

Reach the peer

NAT and firewalls make path establishment part of the design.

Two devices may both have private addresses and still need to communicate. Interactive systems gather candidates, test possible paths, and select a working route. STUN can help an endpoint learn a public mapping. TURN can relay traffic when direct connectivity is blocked or unreliable.

A signaling service may authenticate users, exchange offers and answers, and coordinate reconnection. It usually helps the peers meet; it is not necessarily the path that carries every audio, video, or data packet.

WebRTC is not the same as signaling.Signaling introduces the peers and their capabilities. ICE-style path checks select connectivity. The media or data transport then carries the live exchange.

Carry media and data

Audio, video, and application data have different meanings.

01

Audio

Voice benefits from low delay and smooth playback; a missing packet is often concealed rather than retransmitted late.

02

Video

Codecs compress frames and adapt quality to available bandwidth, motion, loss, and processing capacity.

03

Data channel

Application data may choose ordered reliable delivery or lower-latency delivery that tolerates loss.

04

Application state

Games and collaboration tools reconcile updates, snapshots, sequence numbers, and authoritative decisions.

Protect the experience

Latency, jitter, loss, and bandwidth shape real-time quality.

Latency is the time for information to travel and be processed. Jitter is variation in packet arrival time. Packet loss removes updates. Bandwidth limits how much information can be sent. A jitter buffer can smooth playback, but it adds delay; a larger video bitrate improves detail, but it increases pressure on the path.

Useful measurements include one-way or round-trip latency, packet loss, jitter, bitrate, frame rate, audio level, and reconnection time. A single ping result cannot describe the quality of a complete voice or video session.

01

Freshness

Prefer current state when an old update has lost its value.

02

Smoothing

Buffer variation when a small delay is better than an uneven experience.

03

Adaptation

Change bitrate, resolution, frame rate, or update frequency as conditions change.

Keep the session useful

Recovery must distinguish connection state from application state.

A connection can fail while the user, room, document, match, or call still exists. Reconnection may require a new transport, renewed authentication, a fresh offer, or a state snapshot. Heartbeats and timeouts detect failure; sequence numbers, acknowledgements, idempotent operations, and version checks help repair state.

Applications should decide what can be dropped, replayed, merged, or requested again. Replaying every old media packet is usually wrong, while replaying a missed document operation may be essential.

Reconnect the meaning, not only the socket.A transport reconnect is successful only when the application has restored the state and permissions needed to continue.

Knowledge check

Test your real-time communication model

Answer ten questions.

0 / 10