Communication Networks: Human Analogies (Part 1)

The topic of computer networking might be cloudy and confusing for new students.

This could be due to the many abstract concepts encountered in the subject, as well as the approach taken by instructors and textbooks in introducing it.

One way to remedy this problem, is to observe and relate to how people communicate with each other. By analyzing how humans interact in different circumstances, we can draw analogies for computer networking. The goal of this series is to help students understand networking concepts by way of our daily interactions.

Perhaps, the so-called “TCP/IP model” and the “OSI model” are among the most abstract and problematic of all. However, keep in mind, these are just models that were supposed to help people understand networking concepts and technology.

Before we get started, let us try to remove some of the ambiguity associated with a couple of networking terms.

A mechanism that is used to manage networks and communications in a well-defined manner, is called a protocol. There are perhaps hundreds or even thousands of protocols that were developed. Different protocols solve different problems; more often than not, they work and complement each other.

This brings us to the topic of “layering”. Since each protocol is a well-defined mechanism that performs a specific function, different protocols are categorized into groups or layers. Each layer consists of protocols that seek to fulfil a certain networking requirement. For instance, the protocols of the Physical layer dictate how networking hardware should function. Meanwhile, protocols of the Network layer manage the routes packets should take from source to destination.

When you see the term “layer”, you can think of it as referring to a group of protocols.

This first part of the series, introduces elements from the Application and Transport layers.

It Begins…

Consider the following two scenarios:

• (A) Ordering food at a restaurant.
• (B) Money withdrawal at a bank branch.

The image below provides a visual reference for both scenarios. Read the discussion that follows to compare and contrast.

Figure 1. To the left is scenario (A), and to the right scenario (B)

In order for any of the above two services to be conducted, there need be a set of orderly communications between the server/teller and the client.

These transactions could involve information (name, dish number) or items (food, money) exchange.

These transactions need be carried out in a certain order or fashion (using a protocol). Now, let us take a look at the simpler of the two scenarios, ordering food.

Scenario (A)

• Client: Hello
• Server: Hello, how can I help you?

Client: I would like to have one cheeseburger please.

Server: Sure, anything else?

Client: Just the burger please.

Server: that would be 5 $ only.

*Client hands in the money*

*Server serves the burger*

• Client: Thank you.
• Server: See you next time.

The first part of this communication, represents the greeting/handshake segment. This is necessary to establish a proper connection between the client and the server.

The segment of the conversation in italic, is the focus of the application layer. In here, the client identifies the purpose of his communication. He wants to order/get a cheeseburger. The server offers him the burger in return for some money. This is what the service (or application) is all about. The exchange of data or receiving an item.

Finally, the client and the server end the current transaction and perhaps tend to other business.

This was a very simple example for the capability provided by the Application layer. This layer encompasses many protocols which provide mechanisms to get and offer web resources in a well-defined manner. Such protocols formulate client requests and server responses in packets. They package relevant data and organize it within the packet. The request-response sequence is managed by these protocols. Examples are: the Hypertext Transfer Protocol (HTTP) and the File Transfer Protocol (FTP).

The first and last segments of the conversation (greetings and goodbyes) do not exactly represent any part of the intended service or application. They are, however, very important for the proper initiation and closing of the communications session. Both are functionalities offered by the Transport layer. We shall talk more about the Transport layer soon.

Scenario (B)

Now, let us take a look at the more sensitive case of money withdrawal :

• Client: Hello.
• Teller: Hello, how can I help you?
• Client: I would like to withdraw money from my chequing account.
• Teller: Sure, may I have your bank and ID cards please?
• Client: yes, here is my bank and ID cards.
• Teller verifies the client and hands back his cards to him.

Teller: Thank you, I have verified your identity. How much would you like to withdraw?

Client: 1000$ please.

*Teller hands the money*

• Client: thank you, that is all for today.
• Teller: You are welcome, see you again.

Let us take a look at what happened. This conversation could also be segmented into multiple parts: Greeting/handshake, Authentication, Transaction, Closing/End.

As in the previous scenario, the greetings and closing segments are formalities that are needed for proper initiation and closing of the communications session.

What is new in this scenario is the authentication procedure. The goal of the procedure is to provide information protection. Such a security measure is needed and could be found in different kinds of scenarios. In networking, this feature or function is usually considered as part of the services offered by the Transport layer. Yet, one can still say that it has a place in the Application layer as well. The line could be gray at times. An example of a secure communications protocol is SSL/TLS. It is used regularly in web applications to secure client-server communication sessions.

Now, back to scenario (B). The actual business transaction that took place is embodied in the client’s request to withdraw money and the teller handing over the money to the client. In networking , the exchange of resources or information could be done via HTTP.

To reiterate, HTTP is used by clients to request for data/resources from web servers. It is also used by web servers to respond to these requests. HTTP does that by appending fields to the packet which identify the message type (request/response), the requested resource location (URL), and the body of the message (data/file).

Figure 2. The Client-Server model and HTTP.

Finally, think about what would happen if the teller or server does not have or can not give out what the client asked for. They would still have to give him a reply; albeit, a negative one. HTTP allows servers to identify the type of response they have for a client. Response codes could take on different values to represent the different possible types of replies. For example, if a server has a positive response to a client’s request, then it would append a Code “200 OK” to the HTTP packet. More on the details of HTTP will follow in a future article.