Processes Communicating

Processes Communicating

Before building your network application, you also need a basic understanding of how the programs, running in various end systems, communicate with each other. In the terminology of operating systems, it is not in fact programs but processes that communicate. A process can be thought of as a program that is running within an end system. When processes are running on the same end system, they can communicate with each other with interprocess communication, using rules that are governed by the end system's operating system. But in this blog we are not specifically interested in how processes in the same host communicate, but instead in how processes running on different hosts (with potentially different operating systems) communicate.

Processes on two different end systems communicate with each other by exchanging messages across the computer network. A sending process creates and sends messages into the network; a receiving process receives these messages and perhaps responds by sending messages back. "Network Application Architectures" Figure 1, demonstrates that processes communicate with each other by using the application layer of the five-layer protocol stack.

Client and Server Processes 

A network application is made of pairs of processes that send messages to each other over a network. For instance, in the Web application  a client browser process exchanges messages with a Web server process. In a P2P file-sharing system, a file is transferred from a process in one peer to a process in another peer. For each pair of communicating processes, we usually label one of the two processes as the client and the other process as the server. With the Web, a browser is a client process and a Web server is a server process. With P2P file sharing, the peer that is downloading the file is labeled as the client, and the peer that is uploading the file is labeled as the server.

You may have observed that in some applications, such as in P2P file sharing, a process can be both a client and a server. In fact, a process in a P2P file-sharing system can both upload and download files. However, in the context of any given communication session between a pair of processes, we can still label one process as the client and the other process as the server. We define the client and server processes as follows:

In the context of a communication session between a pair of processes, the process that begins the communication (that is, initially contacts the other process at the beginning of the session) is labeled as the client. The process that waits to be contacted to begin the session is the server.

In the Web, a browser process initializes contact with a Web server process; thus the browser process is the client and the Web server process is the server. In P2P file sharing, when Peer A asks Peer B to send a particular file, Peer A is the client and Peer B is the server in the context of this particular communication session. When there's no confusion, we'll sometimes also use the terminology "client side and server side of an application". At the end of this section, we'll step through simple code for both the client and server sides of network applications.

The Interface Between the Process and the Computer Network

As noted above, most applications are made of pairs of communicating processes, with the two processes in each pair sending messages to each other. Any message sent from one process to another must go through the underlying network. A process sends messages into, and receives messages from, the network through a software interface called a socket. Lets look at an analogy to help us understand processes and sockets. A process is similar to a house and its socket is analogous to its door. When a process wants to send a message to another process on another host, it shoves the message out its door (socket). This sending process supposes that there is a transportation infrastructure on the other side of its door that will transport the message to the door of the destination process. Once the message arrives at the destination host, the message passes through the receiving process's door (socket), and the receiving processes then acts on the message.

The following figure demonstrates socket communication between two processes that communicate over the Internet (The following figure assumes that the underlying transport protocol used by the processes is the Internet's TCP protocol).

Application processes, sockets, and underlying transport protocol

As shown in this figure, a socket is the interface between the application layer and the transport layer within a host. It is also referred to as the Application Programming Interface (API) between the application and the network, since the socket is the programming interface with which network applications are built The application developer has control of everything on the application-layer side of the socket but has little control of the transport-layer side of the socket. The only control that the application developer has on the transport-layer side is (I) the choice of transport protocol and (2) perhaps the ability to fix a few transport-layer parameters such as maximum buffer and maximum segment sizes  (to be covered in "Transport Layer"). Once the application developer chooses a transport protocol (if a choice is available), the application is built using the transport-layer services given by that protocol. We'll explore sockets in some detail in sections "Socket Programming with TCP" and "Socket Programming with UDP".


network application, end systems, computer network, application layer

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.