Real-Time Data Transmitting With WebRTC

Overview

You've covered how to establish a peer-to-peer connection between a local peer and a remote peer. WebRTC supports real-time communication for other types of data, such as plain texts, images as well as streaming video. In this tutorial, you'll learn how to transmit data via a peer connection.

WebRTC's data transmission capabilities extend far beyond traditional media streaming, enabling a wide range of applications that require real-time, bidirectional data exchange between peers. These capabilities unlock possibilities for collaborative applications, real-time gaming, file sharing, and interactive experiences that were previously difficult to implement in web browsers without plugins or complex server infrastructure.

The peer-to-peer nature of WebRTC data channels provides significant advantages over traditional server-mediated approaches. Data travels directly between peers, reducing latency and eliminating server bandwidth costs for data transmission. This architecture enables applications to scale more efficiently and provides better privacy since data doesn't need to traverse third-party servers.

WebRTC data channels leverage the same underlying infrastructure as media streams, including ICE connectivity establishment, DTLS encryption, and SCTP transport protocols. This shared foundation ensures that data channels benefit from the same robust connectivity and security features that make WebRTC media streams reliable across diverse network environments.

Transmit Data Using RTCDataChannel

WebRTC allows you to transmit data between peers using RTCDataChannel that represents a network channel which can be used for bidirectional peer-to-peer transfers of data, such as plain texts and images.

RTCDataChannel provides a powerful abstraction over the underlying SCTP (Stream Control Transmission Protocol) transport, offering developers both reliable and unreliable data delivery options. The channel can be configured for different delivery guarantees, from reliable ordered transmission suitable for file transfers to unreliable unordered delivery optimal for real-time gaming applications where latency is more important than guaranteed delivery.

The data channel architecture supports multiple concurrent channels within a single peer connection, enabling applications to segregate different types of data traffic. For example, an application might use one channel for reliable chat messages, another for unreliable position updates in a game, and a third for file transfer operations. Each channel can be configured independently with appropriate delivery characteristics.

Data channels automatically handle fragmentation and reassembly of large messages, allowing applications to send data larger than the underlying network MTU without manual chunking. The implementation also includes built-in flow control and congestion management to ensure optimal performance across varying network conditions.

You can create a data channel with the RTCPeerConnection's createDataChannel() method like the example below:

            const dataChannel = peerConnection.createDataChannel('sendDataChannel');
        

The createDataChannel method accepts an optional configuration object that allows fine-tuning of the channel's behavior. Configuration options include delivery ordering (ordered or unordered), reliability settings (maxRetransmits or maxPacketLifeTime), and protocol selection. These options enable developers to optimize data channel behavior for their specific use cases.

Channel labels serve as identifiers that help organize multiple data channels within a single peer connection. Well-chosen labels improve code maintainability and enable debugging tools to provide meaningful information about data channel usage. The label also appears in browser debugging interfaces, making it easier to trace data flow during development.

The timing of data channel creation is important for proper WebRTC negotiation. Data channels should be created before initiating the SDP offer-answer exchange to ensure they're properly included in the session description. Creating channels after SDP negotiation requires renegotiation, which adds complexity and latency to the connection establishment process.

Next, you can transmit the data across the connection with the send() method, which receives string, a Blob, an ArrayBuffer, a TypedArray or a DataView object as a parameter.

            const textarea = document.querySelector('textarea#dataChannelSend');

function sendData() {
  const data = textarea.value;
  dataChannel.send(data);
}
        

The send method's versatility in accepting different data types enables applications to transmit various kinds of information efficiently. String data is automatically encoded as UTF-8, making it suitable for text-based communications like chat messages or JSON-serialized application data. Binary data types (ArrayBuffer, TypedArray, DataView) enable efficient transmission of structured data, images, or other binary content.

Blob objects provide a convenient way to send file data or other large binary content without loading everything into memory simultaneously. This is particularly useful for file sharing applications where large files need to be transmitted efficiently between peers.

The send method operates asynchronously and includes built-in buffering to handle situations where data is sent faster than the network can transmit it. Applications should monitor the bufferedAmount property to avoid excessive buffering, especially when sending large amounts of data or when network conditions are poor.

Error handling for the send method is important because data transmission can fail due to network issues, peer disconnection, or data channel closure. Applications should implement appropriate error handling and retry mechanisms to ensure reliable data delivery when required.

Transmit Data Between Multiple Peers

Now, let's transmit data between multiple peers using the RTCDataChannel API and a peer connection.

Let's assume a local peer want to transmit a plain text message to a remote peer in real time. You can send a plain text message from a local peer to a remote peer by implementing the code below:

            'use strict';

let localConnection, remoteConnection;
let sendChannel, receiveChannel;
const dataChannelSend = document.querySelector('textarea#dataChannelSend');
const dataChannelReceive = document.querySelector('textarea#dataChannelReceive');
const connectButton = document.querySelector('button#connectButton');
const sendButton = document.querySelector('button#sendButton');
const disconnectButton = document.querySelector('button#disconnectButton');

connectButton.onclick = createConnection;
sendButton.onclick = sendData;
disconnectButton.onclick = closeDataChannels;

function createConnection() {
  localConnection = new RTCPeerConnection();
  remoteConnection = new RTCPeerConnection(); 
  sendChannel = localConnection.createDataChannel('sendDataChannel');

  remoteConnection.onicecandidate = e => {
    onIceCandidate(remoteConnection, e);
  };
  remoteConnection.ondatachannel = receiveChannelCallback;

  localConnection.createOffer().then(handleLocalSdp);
}

function handleLocalSdp(desc) {
    localConnection.setLocalDescription(desc).then(onCatch);
    remoteConnection.setRemoteDescription(desc).then(onCatch);
    remoteConnection.createAnswer().then(
        handleRemoteSdp,
        onCatch
    );
}

function handleRemoteSdp(desc) {
    remoteConnection.setLocalDescription(desc).then(onCatch);
    localConnection.setRemoteDescription(desc).then(onCatch);
}

function receiveChannelCallback(event) {
    receiveChannel = event.channel;
    receiveChannel.onmessage = onReceiveMessageCallback;
    receiveChannel.onopen = onReceiveChannelStateChange;
    receiveChannel.onclose = onReceiveChannelStateChange;
}

function onReceiveMessageCallback(event) {
    dataChannelReceive.value = event.data;
}

function sendData() {
  const data = dataChannelSend.value;
  sendChannel.send(data);
  console.log('Sent Data: ' + data);
}
        

This comprehensive example demonstrates the complete workflow for establishing data channel communication between peers. The code implements both the sending and receiving sides of the data channel, showing how the initiating peer creates the channel and how the receiving peer handles the incoming channel through the ondatachannel event.

The implementation follows WebRTC best practices by properly sequencing the SDP offer-answer exchange and ensuring that data channels are created before SDP negotiation begins. This approach ensures that the data channel configuration is properly included in the session description and communicated to the remote peer.

The bidirectional nature of the data channel communication is evident in the code structure, where both peers can potentially send and receive data once the channel is established. This symmetry enables rich interactive applications where both participants can contribute data to the shared session.

The event-driven architecture leverages WebRTC's asynchronous design patterns, ensuring that data channel operations don't block other WebRTC functionality. The separation of concerns between connection establishment, data transmission, and event handling makes the code maintainable and extensible.

Let's break the above code snippet one by one:

• createConnection(): Creates local and remote peer connections and creates an SDP offer from the local peer. Also, it registers onReceiveMessageCallback to the remote peer as a data channel.
• handleLocalSdp(): This one is called by createConnection() after creating the SDP offer. It receives a session description as a parameter and sets it as a local/remote description for each peer. Also, the remote peer creates an SDP answer.
• handleRemoteSdp(): This is called by gotDescription1() after creating an SDK answer. It receives a session description as a parameter and sets it as a local/remote description for each peer.
• onReceiveMessageCallback(): This is called when the remote peer receives data via the data channel and handles an event from the data channel.
• onReceiveChannelStateChange(): Monitors changes to the receive channel’s open/close state.
• sendData(): Sends text messages from a text area by clicking the send button on the web browser.

The createConnection() function orchestrates the entire connection establishment process, including data channel creation and SDP negotiation. The function demonstrates the asymmetric nature of data channel establishment, where only the initiating peer creates the channel explicitly, while the receiving peer obtains the channel through the ondatachannel event callback.

The handleLocalSdp() and handleRemoteSdp() functions implement the standard WebRTC SDP offer-answer exchange pattern, adapted for data channel communication. These functions ensure that session descriptions are properly set on both peers and that the negotiation process completes successfully before data transmission begins.

The receiveChannelCallback() function demonstrates how receiving peers handle incoming data channels. This callback is triggered when the remote peer creates a data channel, and it's responsible for setting up appropriate event handlers for the newly received channel. The function shows the importance of configuring event handlers for message reception, channel state changes, and error conditions.

The onReceiveMessageCallback() function handles incoming data messages and demonstrates how applications can process received data. In this simple example, the data is directly displayed in a textarea, but real applications might perform more complex processing like parsing JSON data, validating message formats, or triggering application-specific logic.

The sendData() function illustrates the straightforward process of transmitting data through an established channel. The function includes logging to provide feedback about data transmission, which is valuable for debugging and monitoring application behavior.

You can utilize the RTCDataChannel API in various ways, such as implementing a chat feature, sharing an emoji feature.

Data channels enable a wide range of collaborative and interactive applications beyond simple text messaging. Real-time collaborative editing applications can use data channels to synchronize document changes between multiple users with minimal latency. The reliable, ordered delivery characteristics of data channels ensure that edit operations are applied consistently across all participants.

Gaming applications particularly benefit from data channel capabilities, using unreliable delivery modes for frequent position updates while maintaining reliable channels for critical game events like scoring or state changes. The low latency characteristics of peer-to-peer data channels provide competitive advantages over server-mediated approaches.

File sharing applications can leverage data channels to implement direct peer-to-peer file transfers without requiring server storage or bandwidth. Large files can be efficiently transmitted using chunking strategies that break files into manageable segments, with progress tracking and error recovery mechanisms built on top of the data channel foundation.

Interactive applications like virtual whiteboards, shared presentations, or real-time drawing tools can use data channels to synchronize user interactions across multiple participants. The bidirectional nature of data channels enables rich collaborative experiences where all participants can contribute simultaneously.

Listen To State Changes Of a Data Channel

You can listen to the state changes of a data channel, such as opening or closing a data channel, and you can update the pages or something depending on the different states:

            sendChannel.onopen = onSendChannelStateChange;
sendChannel.onclose = onSendChannelStateChange;

function onSendChannelStateChange() {
  const readyState = sendChannel.readyState;
  console.log('Send channel state is: ' + readyState);
  if (readyState === 'open') {
    // do something when a data channel is opened
  } else {
    // do something when a data channel is closed
  }
}
        

Data channel state monitoring is crucial for building robust applications that can respond appropriately to connectivity changes and channel lifecycle events. The readyState property provides insight into the current channel status, enabling applications to adjust their behavior based on channel availability.

The 'connecting' state indicates that the channel is in the process of being established but is not yet ready for data transmission. Applications should queue outgoing data during this state and wait for the 'open' state before attempting to send messages. Premature sending attempts will result in errors and potential data loss.

The 'open' state signifies that the channel is fully operational and ready for bidirectional data transmission. This is the optimal time for applications to begin sending queued data, enable user interface elements that depend on data channel functionality, and establish any application-specific protocols that operate over the channel.

The 'closing' and 'closed' states indicate that the channel is being terminated or has been terminated. Applications should handle these states gracefully by disabling data transmission functionality, cleaning up any channel-related resources, and notifying users about the connectivity change.

Advanced applications might implement sophisticated state management that includes reconnection logic, automatic retry mechanisms, and graceful degradation of functionality when data channels become unavailable. State change monitoring provides the foundation for these robust connectivity management strategies.

The open event is triggered in a data channel's onopen event handler when the channel's message transmission is initiated or resumed. Conversely, the close event is dispatched to the data channel's onclose event handler once the channel is fully closed.

The timing of these events is significant for application behavior. The open event fires only after the underlying SCTP association is fully established and the data channel handshake is complete. This ensures that when applications receive the open event, they can immediately begin sending data without additional waiting or verification.

The close event provides final notification that the channel is no longer operational. This event is particularly important for cleanup operations, resource deallocation, and user interface updates that reflect the current connectivity status. Applications should not attempt to send data after receiving a close event, as such attempts will result in errors.

Error events can also occur during data channel operation, typically related to transmission failures, protocol violations, or network connectivity issues. Robust applications should implement error handlers that can diagnose issues and potentially implement recovery strategies.

Additionally, you have the option to monitor these states by independently adding listeners, as demonstrated in the following example:

            addEventListener(open, (event) => {});
onopen = (event) => {};

addEventListener(close, (event) => {});
onclose = (event) => {};
        

The flexibility of event listener registration enables applications to implement modular event handling architectures where different components can independently monitor data channel state changes. This approach is particularly useful in complex applications with multiple subsystems that depend on data channel connectivity.

Multiple event listeners can be registered for the same event, allowing different parts of an application to respond independently to state changes. This pattern enables clean separation of concerns where user interface updates, data management, and business logic can each respond to connectivity events without tight coupling.

Event listener management becomes important in dynamic applications where data channels may be created and destroyed during the application lifecycle. Proper cleanup of event listeners prevents memory leaks and ensures that event handlers don't inadvertently operate on stale channel references.

Modern JavaScript development patterns often favor explicit event listener registration over onopen/onclose property assignment because it provides better composability and more flexible event handling architectures. The addEventListener approach also enables event capture and bubbling behaviors that can be useful in complex DOM-based applications.

Close the Data Channel

Once you don't need to connect the data channel anymore, you need to close the data channel. You can close the data channel with the close() method like the example below:

            function closeDataChannels() {
  sendChannel.close();
  receiveChannel.close();
  localConnection.close();
  remoteConnection.close();
  localConnection = null;
  remoteConnection = null;
}
        

Proper data channel closure is essential for resource management and preventing memory leaks in WebRTC applications. The close() method initiates a graceful shutdown process that notifies the remote peer about the channel termination and releases all associated system resources including network buffers, protocol state machines, and event handler registrations.

The order of operations during closure is important for maintaining consistency across all participants. Data channels should be closed before their associated peer connections to ensure that closure notifications are properly transmitted to remote peers. Closing the peer connection first may prevent proper data channel closure signaling.

Setting connection references to null after closing prevents accidental use of closed connections and helps JavaScript garbage collection reclaim associated memory. This is particularly important in single-page applications where connection objects might otherwise persist beyond their intended lifecycle.

Advanced applications might implement more sophisticated closure patterns that include final data transmission opportunities, user confirmation dialogs, or automatic reconnection preparation. The closure process can also include application-specific cleanup like saving unsent data, updating user interface state, or notifying other application components about connectivity changes.

Graceful closure handling improves user experience by providing clear feedback about connection status and preventing confusing error messages that might result from attempting to use closed channels. Applications should update their user interfaces to reflect the closed state and disable functionality that depends on data channel connectivity.

Emergency closure scenarios, such as network failures or browser page unloading, require different handling strategies. Applications should implement beforeunload event handlers that attempt to close connections cleanly when possible, though network conditions may prevent proper closure signaling in some cases.

In this lesson, you've learned the basic concepts of transmitting data between multiple peers with the RTCDataChannel API. Now, let's create an HTML page that controls transmitting data.