Layers of a Real-Time System

A real-time application consists of:

• Clients
• Real-time communication layer
• Back-end servers

These three work together to achieve business objectives. Each layer’s cooperation and proper function are essential in developing a successful application. For example, a bug in the client could prevent proper connection to the server and reduce its ability to operate instantly. A defect in the server could delay or prevent messages from being sent to a connected client. Before we look at the layers of a real-time system, let’s define real-time.

Levels of a real-time system

There are different levels of guarantee in a real-time system.

• Hard real-time
• Soft real-time

Hard real-time

Hardware systems that have strict time guarantees are considered hard real-time.

Example

An airplane’s control system needs to always respond within strict time limits.

Soft real-time

Soft real-time applications can have several seconds of delay when updating the user’s view, thus minimizing the amount of time the update takes.

A soft real-time application should update to the correct state without user intervention. This course will look at soft real-time applications. Soft real-time is also known as near real-time.

The applications in this course are web-based—they utilize a network to receive requests from and respond to a client. The flow of real-time layers is shown in the following figure.

Clients connect to a server via a two-way communication layer. Each server utilizes a server-to-server communication layer to ensure that real-time messages are delivered across a cluster to the appropriate user. Let’s take a closer look at each layer.

Client

Clients are the entry point to our application from the perspective of users. They are the frontline of an application and exist to display data and controls to the user, send user requests to the server, and process incoming messages from the server to update the interface. Clients can exist in any language that supports networking. It’s most common in the web ecosystem to use JavaScript to power clients. However, applications written in other languages, such as Java and Swift, can connect to the same real-time server.

Important functions of a client

In the context of real-time applications, one of the most important functions a client performs is maintaining a connection to the server.

Without the proper real-time communication layer, the application won’t function as expected. This can prove challenging because many users may be accessing the application from less-than-ideal networks, such as a mobile phone or weak Wi-Fi connection. In the coming lessons, we’ll see examples of testing how our application behaves in these conditions.

Communication layer

The communication layer facilitates data exchange between a server and a client. The communication layer affects how the user experiences the application. If data is not sent instantly, the application will feel slow. So, the communication layer needs to be reliable. Any disconnection could prevent data from being exchanged. The connection between a client and the server is often persistent to reduce latency.

A persistent connection lasts for many requests or even for as long as the client wants to stay connected.

Significant improvements in web communication have occurred over the last few years. The HTTP/1 protocol has been improved upon with HTTP/2. New techniques and technologies, such as server-sent events and WebSockets, have offered new ways to implement real-time communication layers. Improvements in the communication layer have enabled a wave of modern applications that satisfy users’ real-time needs.

Note: This course will focus on WebSockets as a general solution for the communication layer.

Server and client application code shouldn’t be tied to particular communication technology. Of course, there will always be code that uses the communication layer. Still, it can be separated from application behavior to add improvements over time to an existing application. If clients and servers are tightly coupled to a communication layer, it may be challenging to implement a new communication layer in the future. This reduces the maintainability of an application.

Server

A client connects to a single server using the application’s communication layer in a real-time application. The server will keep the connection open for an extended time, often as long as the client wants. This is different from a traditional web request, which uses a short-lived connection. Real-time applications are similar to traditional web applications in fundamental ways—ultimately, the server receives a request from a client and processes it. One significant difference between conventional web requests and real-time requests is statefulness.

Stateless requests

HTTP web requests are stateless, meaning that the server doesn’t maintain a state between requests. A client making HTTP requests must send states, such as cookies, with each request. A real-time server can associate states, such as user or application data, with a specific connection. This allows real-time systems to avoid setting up the world with each request, which means our application will do less work and respond to requests faster.

A client connects to a single server, but an application has many clients issuing requests. Resilience and performance need to have multiple servers capable of serving requests. In a stateless web-request world, each server can exist in near isolation so that one request doesn’t affect another directly. In a real-time application, it’s often desirable, and even required, to have servers that can talk to each other. For example, real-time chat servers would communicate with each other about who is connected and who needs to receive a particular message.

Distributed systems

Applications that maintain state and behavior across multiple instances are called distributed systems. Distributed systems can bring many benefits, especially to performance, but they also face many challenges. Today, most systems are distributed. We get to decide whether to build them ourselves or let the infrastructure do the work. However, the best developers need to understand the trade-offs either way.

Remember: Every layer is vital in the proper functioning of our application. Still, the server has the highest potential for encountering scalability problems due to the complexity of dealing with many independent clients.