Persistent vs Non-Persistent Connections | Creating a Multiplayer Game Server - Part 2

Bradston Henry - Nov 3 '21 - - Dev Community

In this entry of the "Creating a Multiplayer Game Server" series we will tackle the topic of Persistent vs Non-Persistent Connections in the Client-Server Model.

a Cartoon computer server connects to a watch, cell phone and web browser with a circular line

As we are aiming to build our multiplayer game server it is important for us to understand two different types of communication approaches in regards to the Client-Server Model.

If you are not very familiar with the Client-Server Model, think of how you engage with any website on the internet. For example, checking your favorite news website for interesting news articles. In this example, the "Client" is represented by the browser you are using to load the website. This browser acts as the the element that you as a user interact with to view and read articles on the website. But in order for the website to display those articles, it needs to have access to data that it can display. In most cases, that data is retrieved from some form of "Server". That "Server" is connected to the "Client" in some way that allows you as a user to view articles.

In this series, our "client" with be our Unity3D game and our "server" will be our Node server hosted in Red Hat OpenShift.

So what we will be covering today are two different types of connections that would allow our "Server" to connect with our "Client".

The two different types of connections are the Persistent connection and the Non-Persistent connection. It is important for us to understand the differences between these two as we can only use one to make a reasonably effective multiplayer game and multiplayer game server. In our case we will be using the Persistent connection approach.

Let's break down the differences between the two...

Non-Persistent Connections

As the name donates, a Non-Persistent connection is exactly that; Non-Persistent. In essence, it means the connection between the client and server exist only as long as needed to transfer some form of data or information.

A good illustration and real-world parallel to a non-persistent connection is the process of sending a letter.

Cartoon illustration of man sending letter

Imagine you needed some form of information from your bank and the only way to acquire it was through the mail. What you would do is write a letter with a request for information. You would put that letter in an envelope, put it in a mailbox and it would be delivered to your bank.

Your bank would receive the request, process it and then prepare a response letter. They would put that letter in their mailbox and it would be delivered to you. You would open your mailbox and you would then have the information you originally requested. And just like that, your correspondence with your bank is now completed.

Similarly, web-based applications that use non-persistent connections have a similar interaction between client and server.

Cartoon Man sits at a computer but you cannot see computer screen. An image of a web browser and website are shown projected in front of him

Now, let's take for example, a banking website. Let's say you are interested in hearing about the new services your bank has just unveiled and the information about these services are located on their website's homepage. What you would do is go to their website using your favorite web browser. When you open your browser, you would type in the web address of the bank and press "Go!". Once you press go, you browser (the client) would send a request to the website's servers asking for the data to display their website. The server would receive this request, process it and send back a response (the data needed to display the website in your browser). The browser would receive that data and then would display the website. Once that data is fully received your connection with the website's server is closed (completed).

This is a very common method used in web applications but for a multiplayer game server, this is not very useful. We don't just want to get the information about other players who are playing in our game just once, we want to continuously get updates as changes are happening. And that's where the next connection method comes in handy.

Persistent Connections

And just as the name references, Persistent Connections are "persistent" or continuous connections. It means that the connection between client and server is continuous and does not disconnect unless the server or client manually disconnects in some way.

So as you may have guessed, I like illustrations, so let's use a real-world illustration to illuminate the persistent connection concept further. The best real-world example would have to be a phone call.

Cartoon Man sits on couch talking on his cell phone. a small plant is sitting to the left of the couch

Imagine you would like to call a friend to catch up on life. You would pick up your phone, type in their number and press dial (if needed). Once dialing starts, your friend's phone would ring in an attempt to establish a connection. Once your friend answers the call, your phone call would be connected. From that point on, unless either you or your friend disconnects in some way, you both would be able to talk to each other; taking turns talking and listening. Once one of you hangs-up, the conversation would end and the call would disconnect.

Web-based applications that use the persistent connection method when communicating between client and server act in a similar way.

A cartoon man in a women sit in different windows looking intently at their phones. Two thin arched lines connect them inferring that they are communicating/texting on the phones

So let's looks at an example of a persistent connection application. A great example is a chat application. So now imagine two friends are chatting using any modern chat application via a web browser. Once the two friends enter the chat room, the web browser (the client) will attempt to establish a connection with the server. The server will confirm that the client can connect and will open that persistent connection. Once connected, the server and client will listen to each other; listening for new data to be sent from the other. This essentially allows for both users to chat in real-time as messages will pass from browser to server to browser continuously until one of the friends disconnects in some way (e.g. closes web browser).

As you may have noticed, this is the best method for our multiplayer game and multiplayer game server. Since we will continuously need to know the state of other players as they move and act in the game, this method allows for that capability. Once we establish a connection with the server and client, data can be passed freely and both server and client can always communicate as needed.


Since a Persistent Connection will be needed, what will be using to create that type of connection?

In our case, we will be using WebSocket. WebSocket is a well-known and well-documented persistent communication protocol and will give us a ton of capabilities we will need for our multiplayer game and multiplayer game server.

In the next part in this series, I will be covering the basics of WebSocket as we will be using it heavily throughout the multiplayer game server development process. After that, we will be getting into the nitty-gritty of the code and begin building our multiplayer game server.

I am EXTREMELY excited about the coming parts of this series and I hope you will continue to join me on this journey.

Thanks for learning with me and I look forward to chatting with you all soon.

Upwards and Onwards,

Bradston Henry

==== FOLLOW ME ON SOCIAL MEDIA ====

Twitter: Bradston Dev
Dev.to: @bradstondev
Youtube: Bradston YT
LinkedIn: Bradston Henry

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .