Complete Communication process

Complete Communication process

Introduction:

In this module, we will look at the complete communication process using the TCP/IP model and protocol stack. We have already seen how each layer functions and how the protocols in TCP/IP suit processes each incoming request from applications to 

transfer data across. We will take two real-world cases, first is the HTTP protocol for web transfer and the second is the SMTP protocol, for mail transfer.

It is critical that we understand how the entire communication is being done right in the beginning. In later modules, we will dig deep and look at each of the componentnin detail. The idea of showing the entire communication, in the beginning, is to give 

you a complete picture of what a network does, a kind of ‘bird's eye view' of the entire subject. It will become easier once we have this vision to see how each part fits in1.

This view also enables you to understand how each layer holds its place in the entire stack and how each layer is related to other layers. That will help to learn about the function of the layer in the context of the entire communication stack. It is also seen that a typical category of students (called global students) learn only if they are given the complete view well before each component of the system is studied. So this module is important for all others but essential for them. 

The Entire Communication Process

Now let us look at the entire communication process considering all the layers together. The idea is to see how these layers work in sync to help sender and receiver communicate. Let us begin with a protocol SMTP which is used for sending mail. Let us take a case of sending an email to the address bhtrivedi@glsuniversity.ac.in. Here 

‘bhtrivedi’ is called a mailbox on the mail server of 'glsuniversity.ac.in'. A mail server is one which manages all the emails of its registered users. Every mail server is capable of handling many registered users. Each user is given a typical mailbox which 

is basically a folder to contain his emails. That mailbox is the personal place for that particular user to store its mail which he already wrote but is yet to be sent and the emails which are arrived from other senders. Thus every mail server caters to all mailing needs of all registered users by providing a mailbox and allowing him to use 

that for sending and receiving emails. This mailbox is a temporary station for all emails.

Outgoing mails normally are removed once delivered at the other end and incoming emails are deleted once the user downloads them on his machine. Mail communication is a two-step process where the mailbox acts as an intermediary. All incoming and outgoing emails stop here. Usually, there are two folders named as 

inbox and outbox are specified for these operations.This arrangement of email mailboxes is analogous to having a few mailboxes at the entry of an apartment for each of its residents. The address  is analogous to an apparent address while bhtrivedi is analogous to a physical mailbox. 

Research in pedagogy has revealed that some of us are a typical type of learners known as global learners. It becomes easier (and sometimes essential) for them if the bird’s eye view of the subject is provided in the beginning. If you are not that type, even in that case, it will strengthen your understanding of the subject.

The glsuniversity.ac.in domain name is obtained by the university where the author works. All employees of GLS university are given a unique mailbox under that domain name. The mail server’s administrator decides which users can register under it and provides all registered users their username and password and along with it, a mailbox. 

The mail process begins with the user generating that mail with the required content and instruct the mail client to send that mail. At that point in time, the mail client places that mail in the outbox. The mail client, periodically, tries to communicate to the server

and deliver all emails pending in the outbox and bring any emails, if there is, from the server to the user's mailbox. The client and the mail server communicates using this SMTP protocol. Before we embark on the process, let us recap the responsibilities of application and transport layers. 

Two figures, 3.1 and 3.2 depicts the idea of application layer communicating with the transport layer. Figure 3.1 indicates how the application layer takes the services of the transport layer for doing its job. The application (like FTP or SMTP) passes commands 

according to the need for the application layer. For example, if the user wants to download multiple files from a typical server, the application passes a command mget

to the application layer, or if it wants to upload files, it passes a command mput to the server. Both the client and server have a large set of commands, each of which is used for a different purpose. They communicate with each other using these commands and some arguments associated with those commands. For example, a 

command called get (which demands a download of a single file from the server) needs a file name as an argument. 

Application layer passes the command to the transport layer after that. In the case of SMTP, the transport layer is TCP. The transport layer relays that to the receiver’s transport layer for it to pass it the receiving application layer. The transport layer of the sender to the transport layer of receiver communication is described in further detail in 3.2. Mind well, the TCP to TCP communication happens by taking services of layers below as we have studied in the first two modules and depicted in figure 3.2. Closely observe figure 3.1. There are a few ways the application layer interacts with 

the user. A user may run a GUI program (an FTP program with GUI) or a menu-driven CUI (Character User Interface), normally used in old-fashioned mobile phones, or an 

API (which is used by application programs which upload and download files on user's 

behalf).

The application level commands from different input forms are converted to specific instructions at the application layer. A GUI click or CUI character or an API function might lead to a single command at the application layer. This command is then passed to the TCP to send that to the TCP at the receiver. The sender and the receiver interpret these commands uniquely and thus there is no ambiguity while the communication is going on. The unambiguous way to communicate is one of the important goals fulfilled by providing an appropriate protocol for this job.

You can also see how the receiver interprets the commands coming to it and processes them and send them to the mail server. The FTP server or mail server interprets those commands and responds back. In our case, the SMTP server receives

Having the address of the machine is just one part of the puzzle, it only identifies a machine on which the mail server is running. The mail server is actually a process running on that machine and the actual destination of that mail is not the machine but 

the mail server, a process. 

Note that there may be more than one processes running on the server. The mail server is just one of them. When we send something, how would the recipient TCP know that the message is for the mail server and not for anybody else? 

The TCP is not only serving the SMTP traffic but web traffic, FTP traffic, Telnet Traffic and many other types of traffic. It has to differentiate between all these traffic as the 

destination for each type of traffic is different. Web traffic should reach to an HTTP (web) server, mail traffic should reach to an SMTP (mail) server, and so on. It has to identify each type of traffic and deal with them differently by sending them to respective 

servers designed to handle that type of traffic.

The problem is solved by providing a separate number for each service. This integer which indicates service is known as the port number. The mail server's port number is 

usually fixed and known globally. All machines should run their mail servers at port no 254. Similarly, all other server run at a typical port number. Whenever an application (in our case the mail client) communicates, it specifies the port number of the receiving application (in our case the mail server) in the TCP header itself. Thus whenever the receiving TCP finds the receiver’s port number form the segment, it knows that it is to 

be delivered to the mail server. 

Thus this port number is an important entity and is part of every communication a TCP has with a peer. 

Once the DNS provides IP address to the application, our mail client application layer requests the TCP process (which is running below in the TCP/IP protocol stack) to 

establish a connection with the IP address and the port number specified. Armed with both these values, TCP generates a connection request segment with a typical port number in the header for identifying sending as well as receiving processes. TCP passes it to the IP layer below. The TCP segment contains many other things in the header which we will ignore for the time being. TCP also passes the IP address it received from DNS to the IP process. We call this IP address as a receiver’s IP address.

There is an IP address of the sender (also known as a client) also, which is input when the IP is installed on the system or procured by other means. The sender's address is not very useful for processing at the sender side but the receiver's address is. 

The sender's address is kept to help the receiver know who to respond back. Both of these addresses are inserted in the IP packet header. The data unit at the TCP layer is known as a segment while after adding IP headers, at the network layer, it is known 

as a packet so we use the term packet header here. 

The IP layer (that means the IP process running beneath the TCP process) looks at the destination IP address and decides where to send that packet next. Note that the IP process takes the help of a routing table it has already created communicating with neighbors. It is possible that our recipient is ten networks away on a specific path or 

may be part of the very network the sender belongs to. The IP layer's most important function is to set the packet on its route by passing it to the next immediate neighbor. 

The IP layer decides the router on the next network as a next immediate receiver for this packet5. Then it prepares the header including the sender's and receiver's IP addresses. The TCP segment received is embedded inside this packet. Then the IP process passes the packet to the NIC or network interface card (the Ethernet card or

the wireless card for example). Additionally, the next immediate neighbor’s IP address is converted to a physical address6 (the physical address is also known as a link address or a MAC address) and passed to the data link layer with the packet.

 

This NIC contains the data link layer which generates a frame. The sender's physical address is taken from the sending card itself (as it is the card's own address) and the recipient's address is taken as passed to it from the IP process. Like other cases, the frame also contains many other fields which we ignore for now. 

The frame is now sent to the next immediate router. That router's network interface card (Ethernet card in most of the cases) receives that frame. It is possible that the card receives a packet not destined for it. There are a few reasons for this case. It may be done when there is an error in the communication system. The second possibility is the received packet being a broadcast or multicast packet. Broadcast means relaying a message to every machine in the network, while multicast means sending to a specific group of machines. If the machine is a part of a multicast group, then the card may receive that packet. If the card receives a packet with the destination address of a group the machine belongs to, then the card will have to accept that packet. 

Similarly, in the case of a broadcast address, the card must accept that packet.5 Though the IP elaborates the entire path, it only decides to send it to next router and next router decides the path further for providing the router’s autonomy that we discussed earlier.

6 The IP address of the immediate next recipient is also converted to the recipient's physical address by means 

of a process known as address resolution. Address resolution is also a complicated process based on typical 

message exchanges in IPv4. IPv6 follows a simpler method of having an IP address which contains the physical 

address as part of it. Thus getting a physical address from an IP address requires a simple extraction process When the physical layer receives the frame in the form of bits, it is passed up. 

The data link layer now understands the bit streams received as a frame. It checks the destination address which is the card's own address or a multicast or broadcast address. If it is ok, the content of the frame (i.e., the network layer data, the packet) is passed up to the network layer. The data link layer might decide to report back to the 

sender in case of an error or simply ignore the error (but do not give the packet up as it is garbled). We will see when a data link layer may prefer to report an error and when it won’t later while studying different data link layers in module 13 and 14. 

Once the data link layer passes the packet to the network layer, the job of network layer starts. The network layer now checks for the IP address of the destination. If that 

address is not it's own, it has to forward that packet. In the case of intermediate routers,the destination network's address is not their own address, so they have to route that 

packet to some other router. They now refer to the routing table. This table suggests 

the route for reaching a given destination. Once the router learns from the table where 

to send the packet, the router constructs a new frame. The new frame will contain the 

sender's address as the router's own address and the receiver's address as the next 

destination router’s address. Then it is passed to the physical layer to transmit it to the 

physical layer of the next router. Remember that the next router is decided at the 

network layer looking at the routing table.

The network or IP layer sometimes communicate on its own to their neighbor 

machine's IP layers or entire network's machine's IP layers. Communicating with them, 

they exchange information about their neighbors and some observations about them 

(for example, how far they are, how much time it takes for them to reach to those 

neighbors, etc.). This process demands additional work from the routers apart from 

passing packets coming from various users. This process (communicating with the 

neighbors or other nodes of the network) results in the routing table. That is why this 

process is known as the routing process. One can easily see that the routing process 

is the prerequisite to the forwarding process as it constructs the routing table as an 

outcome. This routing table is used for forwarding for some amount of time. After that, 

the routing process is executed once again to gauge the changes made to network 

topology. In some cases, whenever a router finds out some update about its 

neighbors, for example having a new router in the vicinity, or an old router has gone 

down, it will start a routing process. In whichever fashion it is done, the routing table 

generated out of it is a reflection of the network's topology (which node is connected 

to whom and how it can be reached) at that point of time.

It is important to see that the router processes this message until the network layer 

and not let it go up. This message is not for the router and the transport layer data is 

of no use for the router and hence it is not forwarded up. The transport layer data 

which is contained by this network layer is to be opened only by the receiver’s transport 

layer. 

The only information needed by this router to forward this packet to the right 

destination is the receiver's address, looking at which they can find out where to send 

the packet next. The router will be able to route successfully with the data available at 

the network layer itself. That is why when the message reaches the network layer of 

an intermediate router, it just takes a return journey back to the physical layer and does not go up. During the return journey, the TCP segment is not opened and IP 

headers do not change (except for two fields which has nothing to do with the data). 

However, the frames are constructed afresh with the new sender and receiver 

addresses. Once the frame is constructed, it is pushed by the physical layer to the 

next immediate router it is destined for. 

Then the packet is received by the next router. The next router does similar processing 

to find out next router, for a given destination, from the routing table, construct the 

frame, and send it across. This process will continue until the packet reaches the final 

destination. Please note that with every hop the frames are constructed afresh while 

the IP packet remains the same. 

When the final destination network layer (the network layer of the mail server running 

at glsuniversity) receives the packet, it concludes that the address is it's own. Thus, 

instead of forwarding the packet, it passes the content of the packet up to the transport 

layer. The content of the packet layer is the segment given to it by the sender’s TCP. 

The transport layer of the receiver, upon receiving the segment, sends an 

acknowledgment on the reverse channel in a similar fashion. The transport layer also 

processes the segment for errors. If the transport layer finds everything ok, it passes 

the data up to the application layer and the application acts upon the command sent 

by the sender7. 

In our case, the command is coming from a mail client for a mail server. We have 

looked at one typical example in the previous module indicating typical mail client 

commands and responses from mail servers. The client and server communication 

consists of many such commands. The commands provide mail handshake process, 

identifying sending and receiving parties, specifying the types of content (the 

attachments of different types demand different processing) and making sure both 

communicating parties take over once the handshake is done. This command can be

any one of the commands used for this communication process. The server decides 

to respond back based on what it has received. Once the server decides the response 

and is ready with it, it instructs the TCP running in the machine to send the response 

back to the client. The response comes back in exactly the same fashion, each layer 

deciding what to do and processing that information into any emails waiting at this 

server to be downloaded as well, it is quite possible that both sender and receiver 

might be sending emails one after another to each other and it is possible that the 

emails in both directions are flying at the same point in time), it will send the first block 

of that mail now and will continue to do so till the mail gets over8. The process includes 

the use of routers, generation of frames and passing bits across physical layers as the 

request did. The routers along the path decide the route based on local conditions like 

the routers while the request is being sent.

One critical point is, the path of server's response is independent of the path of the 

request and thus, it is possible that the path through which the request has come is different than the path through response traveled. Both decisions are independent of 

each other. 

In fact, the process is quite similar to other clients and servers. For example, if the 

sender has sent the command ls to the receiver which is a Telnet server, then the 

receiver interprets that the sender wants to have a directory listing. It acts upon that 

command and prepares the directory listing. Then it sends the listing back on the 

reverse channel exactly like the previous case9. In fact, the clients and servers decide 

what they want to send and receive, based on the user’s requirements and their need, 

but the working of TCP remains the same. TCP only transfers the content given to it 

by the application and send it across to the other end. The application assumes that 

service and gets that service without bothering about how that service is provided. 

Thus TCP is said to work in a transparent manner.

Applications are not needing to bother about how the services are provided is a very 

clever design. The TCP may decide to retransmit segments as pert its own policy 

(TCP, in various incarnations, did change the policies for retransmissions), it may 

decide the segment size, content and may change the header based on newer 

requirements but the client and server coding is not affected. Once a client is designed 

to work in a typical fashion, it might only need to send and receive data, as long as the 

TCP provides that service, it can remain free to change its way of working. Similarly, 

the clients and servers can change their code as per their designer’s wish. As long as 

they need only the set of services TCP offers them, there is no need to change the 

underlying TCP. This is the principle of independence of layers which we are 

mentioned in the previous module. 

The layers can evolve on their own without 

bothering about other layers. Only the interface or the type of service they want to 

have needs to remain the same. For other services, one needs to have a different 

transport layer protocol.

Fortunately, the TCP/IP model provides other alternatives 

called UDP and SCTP for providing a different set of services. The application 

designers are free to choose the transport layer they want to have at the time of design.

Another case of web page access We have taken mail as one example. Now we will take another example, the web 

access process of reiterating how each layer functions and how the entire 

communication process is managed. The idea is to look at some of the additional 

issues which we did not encounter in the previous case. 

Mail communication uses SMTP protocol while the web page access uses the protocol 

known as HTTP or Hypertext Transfer Protocol. The browser that we use is an 

example of an HTTP client and it communicates to the web server for accessing the 

web pages. The communication process is very different than mail but the services 

that it needs remain the same. The very TCP which provides the service to SMTP also 

provides similar service to HTTP. TCP provides retransmission, timer management, 

error handling, and many other services to all applications running on top it, including 

SMTP as well as the HTTP that we are going to discussing now.