CN_BCS502_Module5.1_Notes
CN_BCS502_Module5.1_Notes
Module – 5
Introduction to Application Layer: Introduction, Client-Server Programming
Standard Client-Server Protocols: World Wide Web and HTTP, FTP, Electronic Mail, Domain
Name System (DNS), TELNET, Secure Shell (SSH)
Textbook:
1. Behrouz A. Forouzan, Data Communications and Networking, 5th Edition, Tata
McGraw-Hill,2013.
Reference Books:
1. Larry L. Peterson and Bruce S. Davie: Computer Networks – A Systems Approach, 4th
Edition, Elsevier, 2019.
2. Nader F. Mir: Computer and Communication Networks, 2nd Edition, Pearson Education,
2015.
3. William Stallings, Data and Computer Communication 10th Edition, Pearson Education,
Inc., 2014.
Web links and Video Lectures (e-Resources):
1. https://www.digimat.in/nptel/courses/video/106105183/L01.html
2. http://www.digimat.in/nptel/courses/video/106105081/L25.html
3. https://nptel.ac.in/courses/10610
1. Introduction
The application layer provides services to the user. Communication is provided using a
logical connection, which means that the two application layers assume that there is an
imaginary direct connection through which they can send and receive messages. Figure
shows the idea behind this logical connection.
Ex. The telephone network was originally designed to provide voice service: to allow people
all over the world to talk to each other. This network, however, was later used for some other
services, such as facsimile (fax), enabled by users adding some extra hardware at both ends.
The layered architecture of the TCP/IP protocol suite, however, makes the Internet more
flexible than other communication networks such as postal or telephone networks. Each layer
in the suite was originally made up of one or more protocols, but new protocols can be added
or some protocols can be removed or replaced by the Internet authorities.
The application layer, however, is somewhat different from other layers in that it is the
highest layer in the suite. The protocols in this layer do not provide services to any other
protocol in the suite; they only receive services from the protocols in the transport layer.
Since the application layer is the only layer that provides services to the Internet user, the
flexibility of the application layer, allows new application protocols to be easily added to the
Internet, which has been occurring during the lifetime of the Internet.
There are several application-layer protocols that have been standardized and documented by
the Internet authority, and we are using them in our daily interaction with the Internet. Each
standard protocol is a pair of computer programs that interact with the user and the transport
layer to provide a specific service to the user.
A programmer can create a nonstandard application-layer program if she can write two
programs that provide service to the user by interacting with the transport layer.
Ex. A private company can create a new customized application protocol to communicate
with all of its offices around the world using the services provided by the first four layers of
the TCP/IP protocol suite without using any of the standard application programs.
There are normally some server processes that can provide a specific type of service, but there
are many clients that request service from any of these server processes.
The server process must be running all the time; the client process is started when the client
needs to receive service.
Limitations:
Several traditional services are still using this paradigm, including the World Wide Web (WWW)
and its vehicle HyperText Transfer Protocol (HTTP), file transfer protocol (FTP), secure shell
(SSH), e-mail, and so on.
Mixed Paradigm:
Mixture of the two paradigms by combining the advantages of both.
For example,
• A light-load client-server communication can be used to find the address of the peer that
can offer a service.
• When the address of the peer is found, the actual service can be received from the peer
by using the peer-to peer paradigm.
The idea of sockets allows us to use the set of all instructions already designed in a programming
language for other sources and sinks. For example, in most computer languages, like C, C++, or
Java, we have several instructions that can read and write data to other sources and sinks such as
a keyboard (a source), a monitor (a sink), or a file (source and sink).
Sockets:
• Although a socket is supposed to behave like a terminal or a file, it is not a physical entity
like them; it is an abstraction.
• It is an object that is created and used by the application program.
• Communication between a client process and a server process is communication between
two sockets, created at two ends, as shown in Figure.
UDP Protocol:
• UDP provides connectionless, unreliable, datagram service.
• Connectionless service means that there is no logical connection between the two ends
exchanging messages. Each message is an independent entity encapsulated in a datagram.
• UDP does not see any relation (connection) between consequent datagrams coming from
the same source and going to the same destination.
• UDP is not a reliable protocol. Although it may check that the data is not corrupted during
the transmission, it does not ask the sender to resend the corrupted or lost datagram.
• For some applications, UDP has an advantage: it is message-oriented. It gives boundaries
to the messages exchanged. An application program may be designed to use UDP if it is
sending small messages and the simplicity and speed is more important for the
application than reliability.
• For example, some management and multimedia applications fit in this category.
TCP Protocol:
• TCP provides connection-oriented, reliable, byte-stream service.
• TCP requires that two ends first create a logical connection between themselves by
exchanging some connection-establishment packets.
• This phase, which is sometimes called handshaking, establishes some parameters
between the two ends, including the size of the data packets to be exchanged, the size of
buffers to be used for holding the chunks of data until the whole message arrives, and so
on.
• After the handshaking process, the two ends can end chunks of data in segments in each
direction. By numbering the bytes exchanged, the continuity of the bytes can be checked.
For example, if some bytes are lost or corrupted, the receiver can request the resending
of those bytes, which makes TCP a reliable protocol.
• TCP also can provide flow control and congestion control.
SCTP Protocol:
• SCTP provides a service which is a combination of the two other protocols.
• Like TCP, SCTP provides a connection-oriented, reliable service, but it is not bytestream
oriented.
• It is a message-oriented protocol like UDP.
• In addition, SCTP can provide multi-stream service by providing multiple network-layer
connections.
• SCTP is normally suitable for any application that needs reliability and at the same time
needs to remain connected, even if a failure occurs in one network-layer connection.
Different clients use different sockets, but the server creates only one socket and changes only
the remote socket address each time a new client makes a connection.
Flow Diagram
server use only one socket each. Figure shows the lifetime of the sockets in the server
and client processes.
• Different clients use different sockets, but the server creates only one socket and
changes only the remote socket address each time a new client makes a connection. This
is logical, because the server does know its own socket address, but does not know the
socket addresses of the clients who need its services; it needs to wait for the client to
connect before filling this part of the socket address.
• There are multiple clients, but only one server. Each client is served in each iteration of
the loop in the server. Note that there is no connection establishment or connection
termination. Each client sends a single datagram and receives a single datagram. In other
words, if a client wants to send two datagrams, it is considered as two clients for the
server. The second datagram needs to wait for its turn. The diagram also shows the
status of the socket after each action.
Server Process:
• A server makes a passive open, in which it becomes ready for the communication, but
it waits until a client process makes the connection creating an empty socket bound to a
well-known port.
• The server then issues a receive request command, which blocks until it receives a
request from a client. The server waits for client requests, processes them, and sends
responses in an infinite loop.
• After each iteration, the server's socket address resets partially, awaiting a new request.
Client Process:
• A client makes an active open, creating an empty socket and sending a request.
• The client waits (blocks) for the server's response, processes it, and then destroys the
socket.
Socket Usage:
• The server uses a single socket throughout its lifetime, dynamically updating the remote
socket address for each new client.
• Each client creates and destroys its socket during communication.
Flow Diagram:
Figure shows a simplified flow diagram for iterative communication using TCP. There are
multiple clients, but only one server. Each client is served in each iteration of the loop.
Server Process:
• In Figure, the TCP server process, like the UDP server process, creates a socket and
binds it, but these two commands create the listen socket to be used only for the
connection establishment phase.
• The server process then calls the listen procedure, to allow the operating system to start
accepting the clients, completing the connection phase, and putting them in the waiting
list to be served. The server process now starts a loop and serves the clients one by one.
• In each iteration, the server process issues the accept procedure that removes one client
from the waiting list of the connected clients for serving. If the list is empty, the accept
procedure blocks until there is a client to be served.
• When the accept procedure returns, it creates a new socket for data transfer. The server
process now uses the client socket address obtained during the connection establishment
to fill the remote socket address field in the newly created socket. At this time the client
and server can exchange data.
Client Process:
The client flow diagram is almost similar to the UDP version except that the client data-transfer
box needs to be defined for each specific case.
Application Layer overview:
▪ Application layer determines how a specific user application should use network.
▪ Application layer is built on transport layer and provides network services to user application.
▪ Application layer defines and performs such applications as e-mail; file transfers, remote
access to computers, real-time video conferencing.
▪ Application layer has its own software dependencies; when a new application is developed its
software must run on multiple machines.
Web Client (Browser) : A web browser is an application for accessing websites. Each browser
usually consists of three parts: a controller, client protocols, and interpreters.
The controller receives input from the keyboard or the mouse and uses the client
programs to access the document. After the document has been accessed, the controller uses
one of the interpreters to display the document on the screen. The client protocol can be one of
the protocols described later, such as HTTP or FTP. The interpreter can be HTML, Java, or
JavaScript, depending on the type of document. Some commercial browsers include Internet
Explorer, Netscape Navigator, and Firefox.
Web Server:
The web page is stored at the server. Each time a request arrives, the corresponding document
is sent to the client. To improve efficiency, servers normally store requested files in a cache in
memory; memory is faster to access than a disk. A server can also become more efficient
through multithreading or multiprocessing. In this case, a server can answer more than one
request at a time. Some popular web servers include Apache and Microsoft Internet Information
Server.
Uniform Resource Locator (URL): A web page, as a file, needs to have a unique identifier to
distinguish it from other web pages. To define a web page, we need three identifiers: Protocol,
host, port, and path.
• Protocol: The first identifier is the abbreviation for the client-server program that we
need in order to access the web page. Ex: HTTP (Hypertext Transfer Protocol), FTP
(File Transfer Protocol).
• Host: The host identifier can be the IP address of the server or the unique name given
to the server. IP addresses can be defined in dotted decimal notation, the name is
normally the domain name that uniquely defines the host, such as forouzan.com.
• Port: The port, a 16-bit integer, is normally predefined for the client-server application.
For example, if the HTTP protocol is used for accessing the web page, the well-known
port number is 80. However, if a different port is used, the number can be explicitly
given.
• Path: The path identifies the location and the name of the file in the underlying
operating system. The format of this identifier normally depends on the operating
system. In UNIX, a path is a set of directory names followed by the file name, all
separated by a slash. For example, /top/next/last/myfile is a path that uniquely defines a
file named myfile, stored in the directory last, which itself is part of the directory next,
which itself is under the directory top. In other words, the path lists the directories from
the top to the bottom, followed by the file name.
Web Documents: Web documents are broadly classified into static, dynamic, and active
documents.
• Static Documents: Fixed-content documents stored on a server.
o Characteristics:
▪ Content is determined at creation and cannot be altered by users.
▪ A copy is sent to the client, viewable via a browser.
o Technologies Used:
▪ Created using languages like HTML, XML, XSL, and XHTML.
• Dynamic Documents: Created by the server in real-time upon a browser's request.
o Characteristics:
▪ Content varies with each request, e.g., displaying the current date/time.
▪ The server runs a program or script to generate the content dynamically.
o Technologies Used:
▪ Common Gateway Interface (CGI) (historical).
▪ Modern options:
is established, the object can be transferred. After receiving an object, another three handshake
messages are needed to terminate the connection. This means that the client and server are
involved in two connection establishments and two connection terminations. If the transaction
involves retrieving 10 or 20 objects, the round trip times spent for these hand shakes add up to
a big overhead. When we describe the client-server programming at the end of the chapter, we
will show that for each connection the client and server need to allocate extra resources such as
buffers and variables. This is another burden on both sites, but especially on the server site.
Persistent Connections:
• The server keeps the connection open for additional requests after a response is sent.
• The connection is closed either on client request or after a timeout.
• Typically, the sender includes the data length in the response.
• When the data length is unknown (e.g., for dynamically generated documents), the
server signals this by closing the connection after sending the data, indicating the end.
• Persistent connections save time and resources by reducing the need for multiple
connection setups and terminations.
• Only one set of buffers and variables is maintained per connection, and the round-trip
time for establishing connections is eliminated.
Figure shows the same scenario as in before, but using a persistent connection. Only one
connection establishment and connection termination is used, but the request for the image is
sent separately.
Message Formats:
The HTTP protocol defines the format of request and response messages, structured in four
sections. In request messages, the first section is the request line, while in response messages,
it is the status line. The other three sections share the same names in both message types but
differ in content. These similarities are limited to naming conventions, with distinct details in
each message type.
Request Message:
• The HTTP request message begins with a request line containing three fields: method,
URL, and version, separated by spaces and terminated with carriage return and line
feed.
• Methods define the request type:
o GET: Retrieves data; body is empty.
o HEAD: Retrieves metadata or tests URL validity; body is empty.
o PUT: Uploads a new web page to the server (if permitted).
o POST: Sends data to modify or add to a web page.
o TRACE: Debugging; echoes the request back.
o DELETE: Deletes a web page (if permitted).
o CONNECT: Reserved for proxy server use.
o OPTIONS: Retrieves properties of a web page.
• The URL specifies the address and name of the web page.
• The version indicates the HTTP protocol version, e.g., 1.1.
• Header lines may follow, providing additional information from the client to the server.
Each header has a name, colon, space, and value.
• The body is optional and contains data or files to be sent, typically with PUT or POST
methods.
Response Message:
• The HTTP response message consists of a status line, header lines, a blank line, and
sometimes a body.
• The status line includes three fields separated by spaces:
• Version: Specifies the HTTP protocol version (e.g., 1.1).
• Status code: A three-digit number indicating the request status:
o 100 range: Informational.
o 200 range: Success.
o 300 range: Redirection to another URL.
o 400 range: Client-side error.
o 500 range: Server-side error.
• Status phrase: A textual explanation of the status code.
• Response header lines provide additional information from the server to the client,
formatted as a header name, colon, space, and value.
• The body, if present, contains the document or data being sent to the client; it is absent
in error responses.
Conditional Request:
• A client can include conditions in its HTTP request.
• Common Condition - Time/Date: The client uses the If-Modified-Since header to
request the page only if it has been modified after a specified date and time.
• This mechanism helps reduce unnecessary data transfer by avoiding the delivery of
unmodified content.
Cookies:
Cookies are small pieces of data stored on the user's device by a web browser. They are created
by websites to store information about the user's session or preferences as HTTP is a stateless
protocol.
Creating and Storing Cookies:
1. When a server receives a request from a client, it stores information about the client in a
file or a string. The information may include the domain name of the client, the contents
of the cookie (information the server has gathered about the client such as name,
registration number, and so on), a timestamp, and other information depend ing on the
implementation.
2. The server includes the cookie in the response that it sends to the client.
3. When the client receives the response, the browser stores the cookie in the cookie
directory, which is sorted by the server domain name.
Functionality of Cookies:
• Cookies are stored on the client side and included in requests to the server if a match is
found.
• Servers use cookies to identify returning clients without revealing their content to the
browser or user.
Applications of Cookies:
• E-commerce:
o Track shopping cart items (e.g., item details and prices) and update the cookie
with new selections.
Privacy Concerns:
• Cookies used by advertising agencies for tracking user behavior are controversial.
• There is a need for regulations to protect user privacy.
Cookies help the server maintain continuity and provide personalized shopping experiences,
even during intermittent interactions.
Use of Cookies in an Electronic Store (Scenario) as shown in following Diagram
1. Shopping Cart Creation:
a. The store server creates an empty shopping cart (list) for the client and assigns
a unique ID (e.g., 12343).
b. The server sends a response containing product images and links, along with a
Set-Cookie header storing the cart ID.
2. Cookie Storage on the Client:
a. The browser saves the cookie (ID 12343) in a file named after the store (e.g.,
BestToys).
b. The cookie is not disclosed to the shopper.
3. Toy Selection by the Shopper:
a. When a toy is selected, the client sends a request to the server, including the cookie
(ID 12343) in the Cookie header.
b. The server uses the cookie to identify the shopper and retrieves their shopping
cart.
Cache Update :
• Proxy servers need strategies to determine how long to retain cached responses before deletion
or replacement.
• One approach involves maintaining a list of sites that update content infrequently, such as a
news agency updating its page daily.
• Proxy servers can retrieve such content once and keep it until the next expected update.
• Another method uses headers indicating the last modification time, allowing the proxy server to
estimate the validity of the cached information.