The architecture of a chat application

The main purpose of a chat application is to allow multiple people to communicate using their personal computers. One way to accomplish this is by using a network that these computers are connected to, like the internet, and sending data over it.

Unlike applications such as Facebook Messenger or WhatsApp, which are primar-ily used for one-to-one communication, the chat application developed in this chapter will primarily support group communication (many-to-many) similar to Internet Relay Chat (IRC) or Slack. This means that a single message will be sent to multiple users.

3.1.1 What will the finished application look like?

Let’s say I just watched the latest Game of Thrones episode and am now excited to talk with my friends about it. I’ll call them John and Grace, in case they don’t appreciate me using their real names in this book. The conversation might go something like this (no Game of Thrones spoilers, I promise).

Dominik said: What did you guys think about the latest Game of Thrones episode?

Grace said: I thought Tyrion was really great in it!

John said: I agree with Grace. Tyrion deserves an Emmy for his performance.

At the end of this chapter, you’ll have built an application that will allow this discus-sion to take place. Let’s see what the finished application will look like in the context of the preceding conversation.

Listing 3.1 Conversation between me, John, and Grace about Game of Thrones

I first asked John and Grace what they thought of the latest Game of Thrones episode. I did this by entering my message into the chat application and pressing the Enter key to send it (figure 3.1).

Both John and Grace will receive this message on their computers, and the client application will show it to both of them in the same way (figure 3.2). Note how my mes-sage is prefixed by “Dominik said,” letting John and Grace know who sent the mesmes-sage.

Grace can now answer my question by typing in her response and pressing Enter; John and I will receive her reply. This way, we can have a discussion over the internet rela-tively easily.

This should give you an idea of what you’re aiming to achieve by the end of this chapter. Sure, it might not be as impressive as a full-blown application with a graphical user interface, but it’s a start.

Now let’s move on to discussing some of the basic aspects of this application, in particular, its network architecture.

NETWORKARCHITECTURESANDMODELS

There are two primary network architectures that can be used for this application: peer-to-peer networking and the client-server model. With peer-peer-to-peer networking, there’s no server; instead, each client is connected to multiple other clients that then exchange information between each other. With the client-server model, there’s a single server to which all the clients connect. The messages are all sent to the server, and the server redistributes them to the correct clients. Figure 3.3 shows how these models compare.

The client-server model is the simpler of the two, and because it works well for the kind of application that you’ll be writing, we’ll use it.

Figure 3.1 My screen after I send the message

Figure 3.2 John’s and Grace’s screens

Another thing to consider is the transport protocol, which you’ll use to transfer mes-sages in your application. The two major protocols in use today are TCP and UDP. They’re used widely for many different types of applications, but they differ in two important ways.

The most important feature of TCP is that it ensures that messages are delivered to their destination. Extra information is sent along with the messages to verify that they have been delivered correctly, but this comes at the cost of some performance.

UDP doesn’t do this. With UDP, data is sent rapidly, and the protocol doesn’t check whether the data arrives at its destination. This makes UDP perform better than TCP, but data transmission is less reliable.

Chat applications should be efficient, but reliable delivery of messages is more important. Based on this aspect alone, TCP wins.

NETWORKING There’s a vast amount of information about networking that’s outside the scope of this book. I encourage you to research this topic further if it’s of interest to you.

THECLIENTANDSERVERCOMPONENTS

Now that you know a bit about the networking side of things, let’s look at how the soft-ware will actually work. The plan is to create two separate applications, or components: a server component and a client component.

When the server first starts, it will begin listening for connections from a client on a specific port. The port will be hardcoded into the server and chosen ahead of time so it won’t conflict with any other application. I wouldn’t want it to prevent you from enjoying a good game of Counter-Strike, would I? Once a connection on that port is detected, the server will accept it and wait for messages from it. A newly received message will be sent to any other client whose connection was previously accepted by the server.

When the client first starts, it will connect to the server address that the user speci-fied on the command line. Once it successfully connects, the user of the client will be able to send messages to the server by inputting them through the command line.

The client will also actively listen for messages from the server, and once a message is received, it will be displayed to the user.

Figure 3.4 shows how the chat application operates in a simple use case involving three clients. Dom, John, and Grace are all running clients connected to the server. In the figure, Dom sends a “Hello” message using their client. The server will accept this message and pass it on to other clients currently connected to it.

Server

Client Client

Client Client

Client

Client Client

Client

Indicates flow of messages

Client-server Peer-to-peer

Figure 3.3 Client-server vs. peer-to-peer

You should now have a good idea of how the chat application will work. The next sec-tion will show you how to implement it.