The Foundation of Realtime Multiplayer, Part 2: Data Transmission Protocols (2024)

Network protocols are important in realtime multiplayer gaming. They ensure players worldwide can play together smoothly. Each protocol has rules that affect how data moves, and this can impact the game.

Choosing the right protocol can make a game feel fast and smooth or slow and disjointed. Here, we’ll talk about the main protocols used in multiplayer gaming. We’ll explain what they do, their advantages, and when to use them. This helps you make multiplayer games that work well and are optimized for player interaction.

For online multiplayer games, sending data is key for players to connect. To get how game data goes from one place to another, we need to know the OSI (Open Systems Interconnection) model. This conceptual framework helps us understand and create the network processes that let multiplayer games work.

The OSI model is divided into seven layers, each with a specific role in handling network communications:

1. Physical Layer: This is the hardware that transmits raw bits over a physical medium like cables, radio frequencies, or fiber optics.
2. Data Link Layer: At this layer, data packets are encoded and decoded into bits. It furnishes the means to transfer data between network entities and might correct errors that may occur at the Physical layer.
3. Network Layer: It’s responsible for transferring data sequences, known as packets, across network boundaries. It establishes, manages, and terminates connections between the local and remote host.
4. Transport Layer: Crucial for multiplayer gaming, this layer provides transparent transfer of data between end systems. It’s where we decide if we want reliability with TCP or speed with UDP — choices that can define a game’s responsiveness.
5. Session Layer: Here, connections between processes, called sessions, are established, managed, and terminated. It’s like a mediator that organizes and synchronizes dialogue between applications.
6. Presentation Layer: Often called the syntax layer, it translates data between the application layer and the network format. Data encryption and compression occur at this level.
7. Application Layer: The topmost layer is where end-user protocols like HTTP, FTP, and, in our case, gaming protocols operate. It provides interfaces and protocols for the applications to communicate over the network.

For multiplayer game developers, the Transport (4th) and Network (3rd) layers are particularly pertinent. These layers deal with how data packets are transmitted and how reliable those transmissions are — factors that can significantly impact game performance.

The Transmission Control Protocol (TCP) operates much like a dependable traffic regulator. It guarantees every data “car” reaches its intended “destination” accurately and in sequence. It’s the gold standard for ensuring reliable data “traffic” on the internet.

TCP operates at the Transport Layer of the OSI model, providing important features like:

• Reliability: TCP manages message acknowledgment and retransmits lost packets, ensuring complete data transfer.
• Ordered Data Transfer: Data packets may take different paths to reach their destination. TCP rearranges data packets in the order they were sent.
• Error Checking: Checksums verify that data is uncorrupted during transmission.
• Flow Control: TCP controls data flow to ensure that network resources are not overwhelmed by managing the packet sending rate.
• Congestion Control: If the network is overloaded, TCP reduces the data transfer rate to help alleviate congestion.

TCP is suitable for gaming scenarios that require accurate data delivery in sequence, such as turn-based games or games with significant updates like in-game purchases or changes to the game environment.

However, this can lead to delays. Ensuring data arrives correctly and in order takes extra time. For fast, real-time games, this can result in lags that disrupt gameplay. Therefore, game developers often have to choose between TCP’s reliability and speed, which might lead them to choose a different approach for some of their game’s networking requirements.

The TCP client triggers communication with the server. It operates on the player’s device in a gaming context. The client initiates the connection via a handshake request to the server. After the connection is established, it can send and receive data from the server. This interaction is essential for actions needing assured delivery like login, score submission, or transactions.

Here’s a simple outline of how a TCP client operates:

1. Initialize: Create a socket object for communication.
2. Connect: Initiate a connection to the server using the server’s IP address and port number.
3. Communicate: Send and receive data using the socket.
4. Terminate: Close the socket once the communication is finished.

TCP client can be created with just a few lines of code in most programming languages.

The TCP server waits for clients to connect. After a client starts a connection request, the server answers to complete the connection. In multiplayer games, the server controls the game state and player information. It manages multiple connections at once, each in its own thread or process, to give real-time updates to all clients.

The server’s main tasks include:

1. Bind: Associate the server’s socket with a specific IP address and port.
2. Listen: Wait for incoming client connection requests.
3. Accept: Accept a connection request from a client, creating a new socket object for the individual connection.
4. Handle: Receive data from the client, process it, and then send a response back.
5. Close: Terminate connections when needed and close the server socket.

The server, usually more complicated than the client, needs to handle multiple connections and keep all clients updated with the game’s present state. In game development, it’s essential to efficiently implement a TCP server. This facilitates a prompt multiplayer setting where actions are processed and reflected in the game world instantly.

Unlike TCP’s reliable delivery, User Datagram Protocol (UDP) is a quick service that doesn’t wait for a reply. UDP is preferred for real-time multiplayer games where speed and efficiency matter more than ensuring every packet is delivered. It works at the Transport Layer, sending messages, known as datagrams, with less overhead than TCP.

Here’s why UDP is important for game developers:

• Speed: UDP doesn’t establish a connection before sending data, which reduces delay.
• Non-Confirmatory: It doesn’t require the receiver to acknowledge the receipt of data, avoiding the overhead of managing acknowledgments and retransmissions.
• Flexibility: Developers have control over handling lost packets, allowing them to implement custom reliability layers tailored to their game’s needs.

UDP, while faster and more flexible, doesn’t ensure delivery, order, or duplicate protection. It’s therefore suitable for data that can withstand some loss, such as real-time positional updates in a fast-paced game.

A UDP client sends datagrams, typically containing real-time gameplay data such as player positions or actions, to the server. This occurs without waiting for an acknowledgment, enabling continuous data sending and ensuring smooth, responsive gameplay.

Here’s a high-level overview of a UDP client’s behavior:

1. Initialize: Create a UDP socket.
2. Send: Send datagrams to a specified server address and port.
3. Receive (Optional): Listen for any datagrams sent back from the server.
4. Terminate: Close the socket when it’s no longer needed.

Coding a UDP client is straightforward, with many programming languages offering libraries that handle the details of socket communication.

The UDP server gets datagrams from clients. Without a connection like TCP, the server hears a specific port and handles incoming data. The server can decide to respond back to the address and port it got the data from.

The basic functions of a UDP server include:

1. Bind: Attach the server’s socket to an IP address and port.
2. Listen: Wait for datagrams to arrive from clients.
3. Process: Read the datagrams and act on them, possibly sending back a response.
4. Close: Close the socket once the server shuts down.

Setting up a UDP server necessitates a strategic approach due to the possibility of datagrams arriving out of sequence, being duplicated, or not showing up. Games typically use UDP to disseminate regular updates to all players, prioritizing the latest update over maintaining all past updates.

WebSocket protocol allows continuous two-way communication between a client and a server. It’s key for applications that need immediate data exchange, like real-time multiplayer games, without the delay and overhead from standard HTTP polling.

WebSocket works through an initial HTTP handshake that upgrades the connection to a WebSocket connection. This upgrade is vital as it allows the protocol to use existing web infrastructure and work through standard web ports.

The WebSocket Client starts the connection and keeps communication with the server open. This allows for real-time message exchange, which is needed for synchronous gameplay.

Client operations usually include:

1. Starting the Connection: The client sends a WebSocket handshake request to the server. If the server supports WebSockets, it answers with an upgrade response, setting up the WebSocket connection.
2. Message Exchange: Once the connection is open, the client can send and get messages in real-time. This is important for sending player actions to the server and getting updates on the game state.
3. Message Processing: The client has to properly process incoming messages, updating the game state or player actions based on the data received.
4. Connection Termination: The connection can be ended by either the client or the server when needed. The protocol provides a way for smooth shutdowns.

WebSocket works on the server side by listening to and accepting connections, processing messages, and responding to clients over the same open connection. This ongoing communication supports the immediate interaction needed for some web applications.

Server-side tasks include:

1. Accepting Connections: The server listens to and accepts WebSocket connections, managing the handshake that upgrades the connection from HTTP.
2. Handling Messages: The server processes received messages, which may involve updating game states, executing actions, or sending responses.
3. Broadcasting: The server can send messages to all clients or specific ones, enabling real-time interactions for multiplayer gaming.
4. Managing Connections: The server oversees active connections, checking for any that need to be closed and managing disconnections.

WebSocket is designed for situations where a continuous, real-time link between the client and server can improve the user experience by offering immediate feedback and updates. However, the choice of communication protocol depends on the specific needs and limitations of the application being developed.

Web Real-Time Communication (WebRTC) is an open-source project that gives web browsers and mobile apps real-time communication through simple APIs. It allows voice calls, video chats, and file sharing between browsers without needing plugins.

WebRTC can work through NATs and firewalls, making it great for direct peer-to-peer communication. This is especially useful in gaming, where direct data streams between players can lower latency and improve the game.

Key Components:

• MediaStream: Captures audio and video streams.
• RTCPeerConnection: Enables audio and video communication between peers.
• RTCDataChannel: Allows bidirectional data transfer between peers.

A WebRTC client can connect to other clients (players) to share real-time data. This is essential for immediate synchronization needs like positional updates in multiplayer games or direct game state information sharing among players.

The client’s operations generally include:

1. Creating an Offer/Answer: For a peer-to-peer connection, one client creates an offer, which is sent to another client who responds with an answer.
2. ICE Candidate Exchange: Both clients swap ICE candidates to find the optimal connection route.
3. Data Transfer: Once connected, clients can directly exchange game data such as player positions or game actions.

While WebRTC is primarily peer-to-peer, servers play a crucial role in the initial connection phase. Servers are used to facilitate signaling, the process by which clients exchange information needed to establish the peer-to-peer connection. This may involve:

1. Signaling Server: Manages the exchange of offer, answer, and ICE candidates between clients looking to connect.
2. STUN/TURN Servers: Helps clients discover their own public IP and negotiate connections through NAT or firewalls.

WebTransport is a new protocol made for today’s web apps that need quick communication. It takes the best parts from older protocols — the reliable and orderly delivery from TCP, the fast, connectionless chatting from UDP, and the secure, session-based talk from QUIC. It’s great for apps that need quick and efficient networking, like complicated web-based multiplayer games.

Key Features:

• Low Latency: Enables faster data transmission to support real-time interactions.
• Selectable Reliability and Order: Lets developers pick between reliable and ordered delivery of different data streams. This suits the unique needs of various game data types.
• Multiplexing: Facilitates multiple, simultaneous streams of data over a single connection, optimizing network efficiency.
• Integrated Security: Built-in TLS encryption ensures secure data transmission, protecting player data and game integrity.

In multiplayer gaming, the WebTransport client is crucial for initiating a secure, low-latency connection with the game server. This connection is vital for the fast exchange of player actions and game state updates, ensuring a seamless and immersive experience.

Client responsibilities include:

1. Making a Connection: Starting a link to the game server with the WebTransport protocol.
2. Sending Data: Efficiently sending and getting game data using WebTransport’s support for reliable and less reliable data streams.
3. Managing Streams: Dealing with various data streams to improve the flow of different game data like player actions, game updates, and voice chat.
4. Ending a Connection: Correctly closing the connection when the game ends or when a player disconnects.

On the server side, WebTransport supports the demands of real-time multiplayer games by managing connections from multiple clients. It processes incoming data, updates the game state accordingly, and sends updates back to all connected clients with minimal delay.

Server-side functionality includes:

1. Connection Management: Accepting and maintaining WebTransport connections, ensuring stable and continuous communication with clients.
2. Data Handling: Processing incoming data to update game states and responding to clients, maintaining the game’s flow and logic.
3. Stream Prioritization: Managing multiple data streams effectively, prioritizing essential game updates to ensure consistent and fair gameplay.
4. Ensuring Security and Performance: Using WebTransport’s security measures while efficiently processing and transmitting game data to sustain high performance.

WebTransport integrates features like low latency and selectable reliability, which are essential for the development of real-time multiplayer games and metaverse experiences. Its support for secure, high-performance communication aligns with the growing complexity of online environments. As the demand for more immersive and interactive platforms increases, the role of efficient data exchange becomes crucial. WebTransport’s capabilities in facilitating effective data transmission could significantly impact the development of future online gaming and virtual worlds, emphasizing the importance of quick and reliable network interactions.

MassiveRealm is the all-in-one serverless backend platform designed for metaverse, multiplayer games, and applications that need multi-user interaction. We let developers build vast worlds without worrying about server management. Currently, we use WebRTC DataChannel with authoritative server for communication. It also supports the sending of unordered and unreliable messages between the browser and server, making the system faster and more efficient in changing conditions.

We know that every project is unique, so we’re always working to grow and adapt. In addition to our current use of WebRTC DataChannel, we’re working to add UDP, WebTransport, and WebSocket as selectable options. We hope to bring these protocols into our platform, allowing the use of more than one protocol in a single game room. This change will make our platform more flexible, helping developers match their projects with their goals and their players’ needs.

In developing real-time multiplayer games, selecting the appropriate network protocol — TCP, UDP, WebSocket, WebRTC, or WebTransport — is crucial. This choice impacts speed, reliability, and complexity. TCP provides ordered data delivery but can cause delays. UDP is quicker but less reliable, fitting for fast games. WebSocket gives a reliable two-way channel for web games. WebRTC allows direct peer-to-peer interaction, reducing delays. WebTransport combines TCP’s reliability and UDP’s speed, making it suitable for different game needs.

The best protocol, or mix of protocols, depends on what the game needs, including things like speed, network conditions, and game mechanics. Using these protocols well can make multiplayer games better, giving players smooth and fun interactions, no matter what kind of network they’re using.

Stay connected by subscribing to our socials 👇

Linkedin | X (Twitter) | YouTube | Discord