Design for Unreliable Connections

In the previous section, we learned how to restrict access to a Channel-based application using authentication. We covered enough to build basic Channel applications, but there’s still more we need to know to build full-featured Channel applications. This section will look at concepts such as Channels in a cluster of servers, how to customize Channel behavior, and how to write tests for Channels.

First, we’ll cover the unreliable nature of internet connections and consider how we can build applications that survive the strange things that can happen with real users. Flaky internet connections, bugs in an application, and server restarts can lead to connection trouble for users.

We’ll then learn about different challenges when using Channels with multiple servers. We’ll see different patterns that can be used to customize the behavior of Channels. These patterns enable us to build more complex flows with complex application requirements. We’ll finish this section by writing tests for our Socket and Channel code. Let’s jump into the challenges of unreliable connections now.

Design for unreliable connections

Clients connect to our real-time application using a long-lived connection. The client’s connection can close or fail at any point; we need to consider this and write code to recover when it happens.

There are certainly expected reasons for a connection to disconnect, such as leaving the application, changing pages, or users closing their laptop while the application is loaded. Also, there are more unpredictable reasons that cause a connection to (erroneously) disconnect. A few examples of this are:

• A client’s internet connection becomes unstable and drops their connection without any other changes.

• A bug in the client code causes it to close the connection.

• The server restarts due to a routine deployment or operational issue.