Welcome to episode 1 of “How It May Work”, a web series where we try to make educated guesses on how software applications around us work. The aim of this series is to provide food for thought for budding programmers and help them get started on DIY projects. In this episode, we are going to talk about chat clients.

We’ve all used chat clients since the early days of the internet. They were the precursors of today’s social networks and have still managed to survive in their original form. So let’s put our thinking hats on and begin our study. A typical chat client:

1. Has a concept of a “friend list”. You can add or remove people from this list given you have their “email ID”. The “friend list” is the directory of people you can interact with.
2. Has a concept of “logging in”. When you do so, people who have you in their friend lists, see you as “online”, or “available”.
3. And most importantly, once a person is online, you can send private text messages to him which will appear in his “chat window”. Modern day chat clients also let us send graphical emoticons and audio snippets. Nowadays it’s also possible to have a “group chat” where you can send and receive messages from a group of users.

Let’s start with #1. We need to maintain a list of friends. Let’s start simple and keep it as file on our computer. The file will be a list of email addresses.

Table 1.0

Table 2.0

Note: Real databases should never store passwords. They always use a “one way hash function” to convert the password into some alphanumeric gibberish. Since this is a “one-way” process, passwords cannot be revealed even when the database is compromised.

Question 1: Why do we need to log in anyways?

Now, let’s tackle the real problem. We want to be able to send a private message to a user in our friend list. To be able to send a message to our friend’s computer over the internet, we will need his “IP Address”.  Now we have hit a roadblock. We don’t have this information anywhere. Our friend list file contains only email addresses. To solve this problem we can save the IP address of a user on the server and download it to our computer, when he is added to the friend list.

To achieve this, we will need the server to remember the IP address. So let’s update Table 2.0 to reflect this:

Table 2.1

There ! Problem solved.  In order to make this work we will now need to update Table 1.

Table 1.1

Now we can look up the IP address from this file and use that to send a private message to his computer. But what if we want to chat from another computer? Without the file, the chat client won’t know who your friends are. So definitely this approach of “statically” storing IP addresses won’t work. We need an approach that is “dynamic” where the data is updated whenever the user changes location. We need a data-store that is always online and always kept up-to-date. And the chat server is the ideal candidate for such a data store.

Let’s add another table to the server, from where we can look up the friend list given any user.

Table 3.0

Table 3.0 has a “one-to-many” relationship between a user’s email address and his friend’s email address.  This means, if there are N users with M friends each, then the table will have N x M rows.

We now have all the pieces needed to create a robust chat network. Let’s review our algorithm.

1. User enters his credentials in the chat client and “logs-in” to the server.
2. The chat server authenticates the user with the credentials stored in its database and stores the current IP address using Table 2.1.
3. The chat client looks up the user’s friend list by retrieving the list of friend email address given the user’s email address using Table 3.0
4. For each friend’s email address, the chat client look’s up the corresponding IP address from Table 2.1.

That’s all for this episode. Until next time, I will leave you with some questions to ponder about.

1. How do we handle “status updates”
2. How can we introduce an “offline messaging” feature?
3. Can we enable “group chatting” only by changing the chat client?