TRANSPORT LAYER

&
APPLICATION LAYER

Prepared by: (1) Dr Tanvir H Sardar, Associate Professor, Dept. of CSE, 2024-25 and (2)
THE TRANSPORT LAYER
5.1. The Transport Service
5.1.1 Services Provided to the Upper Layers
5.1.2 Transport Service Primitives
5.1.3 Berkeley Sockets
5.1.4 An Example of Socket Programming: An Internet File Server
5.2. Elements of Transport Protocols
5.2.1 Addressing
5.2.2 Connection Establishment
5.2.3 Connection Release
5.2.4 Error Control and Flow Control
5.2.5 Multiplexing
5.2.6 Crash Recovery
THE APPLICATION LAYER
5.3. DNS — The Domain Name System
5.3.1 History and Overview
5.3.2 The DNS Lookup Process
5.3.3 The DNS Name Space and Hierarchy
5.3.4 DNS Queries and Responses
5.3.5 Name Resolution
5.3.6 Hands on with DNS
5.3.7 DNS Privacy
5.3.8 Contention Over Names
5.4. Electronic Mail
5.4.1 Architecture and Services
5.4.2 The User Agent
5.4.3 Message Formats
5.4.4 Message Transfer
5.4.5 Final Delivery
5.5. WWW
5.5.1 Architectural Overview
5.5.2 Static Web Objects
5.5.3 Dynamic Web Pages and Web Applications
5.5.4 HTTP and HTTPS
5.5.5 Web Privacy
5.6. Streaming Audio and Video
5.6.1 Digital Audio
5.6.2 Digital Video
5.6.3 Streaming Stored Media
5.6.4 Real-Time Streaming
THE TRANSPORT LAYER
5.1. The Transport Service
This section introduces the transport service, focusing on the type of service it provides to the
application layer. It begins with an overview of transport layer primitives, starting with a simple
hypothetical example to illustrate basic concepts, followed by the commonly used Internet interface.
5.1.1 Services Provided to the Upper Layers
The transport layer aims to provide efficient, reliable, and cost-effective data transmission services to
the application layer by utilizing the network layer's services. The main component of the transport
layer, the transport entity, can reside in the operating system, library packages, or even hardware like
network interface cards.

Fig. The network, transport, and application layers

Key Features:
• Transport Services: Two types exist—connection-oriented (establishment, data transfer, release
phases) and connectionless, similar to the network layer services.
• Purpose:
o Enhances reliability over potentially unreliable network layers.
o Handles issues like packet loss, network failures, and inconsistencies, ensuring uninterrupted
and reliable communication.
o Provides independence from the underlying network primitives, enabling application
developers to work with standardized transport primitives regardless of network specifics.
Why the Transport Layer is Necessary:
• The network layer often operates on external routers controlled by carriers, which users can't
manage directly. The transport layer compensates for any inadequacies by providing error handling,
retransmissions, and recovery mechanisms.
• It isolates application logic from network specifics, ensuring portability and adaptability across
varied networks.
Design Impact:
• Layers 1–4 are seen as the transport service provider, while upper layers are service users.
• The transport layer is the critical boundary between provider and user, offering reliability and
standardization to applications regardless of network imperfections or changes.

5.1.2 Transport Service Primitives

The transport service interface provides application programs with primitives to establish, use,
and release connections, offering reliable communication over unreliable network services. It
simplifies complexity for users by hiding network imperfections.
Key Features of the Transport Layer:
1. Reliable Connection-Oriented Service:
o Ensures error-free communication, even if the underlying network is unreliable.
 o Offers applications a seamless "bit pipe," where data sent appears intact at the
receiving end.
2. Connectionless Datagram Service:
o While simpler, it is primarily used in client-server computing and streaming
multimedia.
o This chapter focuses on connection-oriented services due to their reliability.
3. Transport Entities and Segments:
o Communication between transport entities is via segments, encapsulated within
packets (network layer) and frames (data link layer).

Fig. The primitives for a simple transport service

Client-Server Example:
1. Connection Establishment:
o Server: Executes LISTEN, awaiting client requests.
o Client: Executes CONNECT, sending a connection request segment.
o Server Response: If ready, sends CONNECTION ACCEPTED, completing the
handshake.
2. Data Exchange:
o Uses SEND and RECEIVE primitives.
o Acknowledgments and retransmissions ensure reliable delivery, though these are
abstracted from users.
3. Disconnection:
o Two models:
▪ Asymmetric: A single DISCONNECT ends the connection.
▪ Symmetric: Each direction is closed independently, requiring both parties
to issue DISCONNECT.
Advantages of Layering:
• Hides Complexity: Users interact with a simplified, reliable interface.
• Portability: Applications work across networks without adapting to underlying network
specifics.
• Connection Reliability: Transport entities manage acknowledgments, timers, and
retransmissions.
State Diagram:
Connection establishment and release are managed via events (primitives or incoming
packets). This basic model demonstrates transport layer fundamentals, with
more advanced mechanisms explored in protocols like TCP.

Fig. Nesting of segments, packets, and frames

5.1.3 Berkeley Sockets
Socket primitives abstract transport services, making them accessible and flexible for application
programming. Originally released in 1983 as part of Berkeley UNIX 4.2BSD, sockets became the
standard for network programming, particularly with TCP.
Server-Side Socket Workflow:
1. SOCKET:
o Creates a new endpoint and allocates resources in the transport entity.
o Parameters specify:
▪ Addressing format (e.g., IPv4/IPv6).
▪ Type of service (e.g., reliable byte stream).
▪ Protocol (e.g., TCP).
o Returns a file descriptor for subsequent calls.
2. BIND:
o Assigns a network address to the socket.
o Allows specific address selection, useful for well-known services (e.g., HTTP servers).
3. LISTEN:
o Prepares the socket to accept incoming connections.
o Allocates a queue for multiple incoming requests.
4. ACCEPT:
o Blocks until a connection request arrives.
o Creates a new socket for the connection, leaving the original socket available for other
requests.
o Returns a file descriptor for data transfer.

A state diagram for a simple connection management scheme. Transitions

labeled in italics are caused by packet arrivals. The solid lines show the
client’s state sequence. The dashed lines show the server’s state sequence

Client-Side Socket Workflow:

1. SOCKET:
o Creates a new socket.
o Unlike the server, BIND is not typically required since the client address is
determined automatically.
2. CONNECT:
o Blocks the client process and initiates the connection.
 o The connection is established once the server acknowledges.
3. SEND/RECEIVE:
o Used for full-duplex communication.
o Alternatively, UNIX's standard READ/WRITE system calls may be used if no special
options are required.
4. CLOSE:
o Both sides must execute this to release the connection resources.
o Connection release is symmetric.

Socket API Versatility:

• Connection-Oriented Services:
o Typically paired with TCP to provide a reliable byte stream, abstracting the
complexities of underlying protocols.
• Connectionless Services:
o For datagram protocols like UDP:
▪ CONNECT associates the socket with a remote peer.
▪ SEND and RECEIVE transmit and receive datagrams.
• Other Protocols:
o Supports alternatives like DCCP (Datagram Congestion Control Protocol), providing
message-based services with congestion control.

The socket primitives for TCP

Challenges and Extensions:

1. Grouped Streams:
o Applications like web browsers often use multiple streams for related objects, which
sockets handle separately, leading to inefficiencies (e.g., independent congestion
control per stream).
2. Improved Protocols:
o SCTP (Stream Control Transmission Protocol):
▪ Supports grouped streams for better resource management and congestion
control.
o QUIC:
▪ Provides enhanced performance and security, especially for HTTP/3, using
multiple paths and traffic modes.
3. Future Developments:
o APIs may evolve to better support grouped streams, hybrid traffic types (connection-
oriented and connectionless), and more efficient transport.
The socket API remains a robust and versatile interface for network communication, but
advancements like SCTP and QUIC point toward evolving needs in modern
applications.
5.1.4 An Example of Socket Programming: An Internet File Server

Server Code Overview

1. Setup and Initialization:
o Includes standard headers for network programming.
o Defines constants for SERVER_PORT (8080), CHUNK_SIZE (file transfer block size),
and QUEUE_SIZE (maximum pending connections).
o Initializes the server’s IP address structure using memset and sets relevant fields
like port and IP address using htons and htonl.
2. Socket Creation and Configuration:
o socket(): Creates a socket for communication.
o setsockopt(): Ensures the port can be reused, preventing errors when restarting
the server.
o bind(): Associates the socket with the server's IP address and port.
o listen(): Enables the server to accept incoming connections, specifying a queue
size.
3. Main Loop:
o accept(): Blocks until a client attempts to connect, returning a new socket
descriptor (sa) for communication.
o Reads the requested filename from the client, opens the file, and streams it block-
by-block to the client using read() and write().
o Closes the connection and waits for the next client.

Client Code Overview

1. Invocation:
o Run as:
bash
Copy code
client <server_name> <file_path> > <output_file>
E.g.,
bash
Copy code
client flits.cs.vu.nl /usr/tom/filename > output.txt
o The server must be running and have access to the requested file.
2. Setup and Initialization:
o Validates input arguments.
o Uses gethostbyname() to resolve the server's domain name (e.g., flits.cs.vu.nl) to
its IP address.
3. Socket Operations:
o socket(): Creates a socket for communication.
o connect(): Establishes a TCP connection to the server.
4. File Request and Transfer:
o Sends the filename to the server, including a null terminator to indicate the end of
the filename.
o Reads file data from the socket in blocks and writes it to the standard output.
 5. Error Handling:
o The fatal() function prints error messages and exits, though it is simplified here.

Key Concepts Demonstrated

1. Client-Server Architecture:
o The server handles incoming connections and processes requests sequentially.
o The client initiates connections and sends specific requests.
2. Socket API:
o Illustrates common primitives: socket, bind, listen, accept, connect, send, and
receive.
3. TCP Communication:
o Ensures reliable and ordered data delivery using a bidirectional communication
channel.
4. Blocking Operations:
o Server blocks on accept and read, waiting for client connections and data.
o Client blocks on connect and read for server responses.

Limitations of the Example

1. Sequential Processing:
o The server processes one request at a time, reducing throughput and scalability.
2. Error Handling:
o Minimal error checking and simplistic error reporting.
3. Security:
o No authentication or access control is implemented, making it insecure for real-
world use.
4. Assumptions:
o Assumes the filename fits in the buffer and that it is transmitted atomically, which
may not hold in practical scenarios.
5. Platform Independence:
o Relies on UNIX system calls, limiting its portability.
5.2. Elements of Transport Protocols

The implementation of the transport service by a transport protocol is fundamental in networking,

bridging the application layer with the underlying network. While it shares similarities with data link
layer protocols, the differences stem from the distinct environments in which they operate. Below is a
detailed comparison and analysis based on the provided text.

Similarities Between Data Link and Transport Protocols

1. Error Control:
o Both layers must ensure data integrity and reliability through mechanisms like
retransmissions and acknowledgements.
2. Sequencing:
o Maintaining the correct order of data delivery is essential for both layers.
3. Flow Control:
o Both layers regulate the data rate between sender and receiver to prevent buffer
overflows and data loss.

Differences Between Data Link and Transport Protocols

1. Environment:
o Data Link Layer:
▪ Operates between two directly connected devices using a physical link (wired or
wireless).
o Transport Layer:
▪ Operates end-to-end over a network involving multiple intermediate routers.
2. Addressing:
o Data Link Layer:
▪ No need for explicit addressing; communication occurs directly between
connected devices.
o Transport Layer:
▪ Requires explicit addressing (e.g., IP and port numbers) to identify endpoints
across the network.
3. Connection Establishment:
o Data Link Layer:
▪ Simple and straightforward; the other endpoint is either reachable or not.
o Transport Layer:
▪ Complex due to the need to traverse the network and establish connections over
potentially varying routes and conditions.
4. Packet Behavior:
o Data Link Layer:
▪ Packets follow a fixed route and do not get lost or arrive out of order under
normal circumstances.
o Transport Layer:
▪ Packets may take different routes (in datagram-based networks like IP), leading
to delays, out-of-order delivery, or duplication.
5. Buffering and Flow Control:
o Data Link Layer:
▪ A fixed number of buffers can be allocated per line, as the environment is
predictable.
o Transport Layer:
▪ Must manage a large number of simultaneous connections with fluctuating
bandwidths, making static allocation impractical.
Key Challenges in the Transport Layer

1. Packet Delay and Duplication:

o In networks using datagram routing, packets may:
▪ Take longer, less direct paths.
▪ Arrive out of sequence.
▪ Be duplicated.
o These behaviors necessitate mechanisms like sequence numbers, acknowledgments, and
duplicate suppression to maintain reliability.
2. Dynamic Resource Allocation:
o The transport layer handles multiple connections competing for resources, requiring
adaptive techniques for buffer management and flow control.
3. Initial Connection Setup:
o Establishing a connection in the transport layer (e.g., TCP’s three-way handshake) is
more complex than in the data link layer due to the need to synchronize state across the
network.

5.2.1 Addressing
The establishment of connections between application processes in the transport layer
introduces several concepts, mechanisms, and solutions to efficiently manage endpoint
communication. Here’s a breakdown of the key ideas and procedures described:

Endpoints in the Transport Layer

1. TSAP (Transport Service Access Point):
o Represents a specific transport layer endpoint to which processes can attach to
establish connections.
o Analogous to ports in the Internet (e.g., TCP/UDP ports).
2. NSAP (Network Service Access Point):
o Refers to network layer endpoints, like IP addresses, used for routing data across a
network.
3. Relationship Between NSAPs and TSAPs:
o TSAPs are mapped to NSAPs to establish and manage transport connections.
o A single NSAP may support multiple TSAPs for different applications running on the
same host.

Transport Connection Establishment Example

1. Mail Server Setup:
o A mail server process attaches to a specific TSAP (e.g., 1522) on a host.
o This setup enables it to listen for incoming connection requests.
2. Client Connection Request:
o A client application attaches to a local TSAP (e.g., 1208) and issues a connection
request to the server's TSAP (e.g., 1522).
o A transport connection is established between the client and server.
3. Data Exchange:
o The client sends a message (e.g., an email).
o The server acknowledges receipt and processes the message.
4. Connection Termination:
o Once the communication is complete, the transport connection is released.

Challenges in Identifying TSAPs

1. Stable TSAP Addresses:
o Commonly used for well-known services (e.g., TCP port 25 for mail servers, port 80
for HTTP).
o These addresses are predefined and often listed in configuration files like
/etc/services in UNIX systems.
 2. Dynamic TSAP Discovery:
o For user processes or temporary services, pre-allocated TSAPs are inefficient.
o A mechanism is required to dynamically discover the TSAP of the desired service.

Dynamic TSAP Discovery Using Portmappers:

1. Portmapper Functionality:
o A portmapper process listens on a well-known TSAP.
o It maps service names (e.g., "BitTorrent") to corresponding TSAPs.
2. Steps in TSAP Discovery:
o A client connects to the portmapper.
o The client sends a service name query.
o The portmapper responds with the TSAP of the requested service.
o The client then establishes a new connection directly with the service.
3. Service Registration:
o New services register their service name and TSAP with the portmapper.
o The portmapper maintains an internal database of these mappings.
4. Analogy:
o The portmapper acts like a directory assistance operator, linking names to
numbers.

How a user process in host 1 establishes a connection with a mail server in host 2 via a process server.

Efficient Connection Handling: Initial Connection Protocol

1. Motivation:
o Not all services need to be actively listening on stable TSAPs, as some are rarely
used.
o Maintaining multiple idle servers wastes system resources.
2. Proxy Server Mechanism:
o A proxy server (e.g., inetd in UNIX) listens to multiple TSAPs simultaneously.
o It acts as a central point for incoming connection requests.
3. Workflow:
o A client connects to a service TSAP. If no server is running, the proxy server
responds.
o The proxy server spawns the required service, which inherits the existing
connection.
o The proxy server then returns to listening for other requests.
 4. Benefits:
o Reduces resource usage by only creating servers on demand.
o Simplifies management of rarely used services.

5.2.2 Connection Establishment

This excerpt explains the challenges of establishing reliable network connections, focusing on the
issue of delayed and duplicate packets. The key challenges and solutions are summarized below:
Challenges
1. Delayed Packets:
o Packets can take varying amounts of time to traverse the network, leading to
scenarios where old packets arrive after the connection has already been terminated
or replaced.
2. Duplicate Packets:
o In cases of retransmissions due to timeouts, multiple copies of the same packet can be
generated. If delayed duplicates are mistakenly treated as new packets, this can lead
to unintended actions, such as duplicate bank transactions.
3. Packet Lifetime:
o Networks cannot guarantee that packets disappear after a certain time. Without
proper mechanisms, old packets might interfere with new connections.
4. Resource Limitations:
o Maintaining extensive history for all previous connections (to check duplicates) is
impractical, as it requires indefinite memory retention by network entities.

(a) Segments may not enter the forbidden region. (b) The resynchronization problem.

Solutions
1. Restricting Packet Lifetime:
o Hop Counter: Each packet carries a counter that decrements at every hop; packets are
discarded when the counter reaches zero.
o Timestamping: Packets include their creation time, and routers discard packets older
than a certain threshold.
o Restricted Network Design: Enforces limits on how long a packet can circulate in the
network, though this can be difficult in large, distributed systems.
2. Unique Identifiers:
o Each connection or packet is labeled with a unique identifier, ensuring duplicates can
be recognized and discarded.
o Ensuring sequence numbers do not repeat within the packet lifetime is critical.
3. Clock-Based Sequence Numbers:
o Sequence numbers are derived from a clock that continues running even if the host
crashes. This prevents reuse of old sequence numbers.
4. Three-Way Handshake:
o A reliable protocol to establish connections while preventing interference from
 delayed duplicates:
1. Step 1: The initiating host sends a connection request with an initial sequence
number.
2. Step 2: The receiving host replies with an acknowledgment and its own
sequence number.
3. Step 3: The initiating host sends a final acknowledgment.
o If a delayed duplicate request arrives, it is rejected because the sender and receiver
do not confirm the connection.
5. TCP Improvements:
o PAWS (Protection Against Wrapped Sequence Numbers): Prevents sequence number
wrapping within the maximum packet lifetime by extending sequence numbers with
timestamps.
o Pseudorandom Sequence Numbers: Ensures unpredictability of sequence numbers to
enhance security and prevent attacks.

Key Takeaways
• Reliability in connection protocols requires not only handling common scenarios efficiently
but also robust mechanisms to deal with edge cases like delayed and duplicate packets.
• Techniques like sequence numbering, packet lifetime restrictions, and three-way handshake
are foundational to modern networking protocols, including TCP.
• While additional security measures like pseudorandom sequence numbers have been
implemented to prevent attacks, the underlying principles ensure robustness against
network anomalies.

Three protocol scenarios for establishing a connection using a three-way handshake. CR denotes
CONNECTION REQUEST. (a) Normal operation. (b) Old duplicate CONNECTION REQUEST appearing out of
nowhere. (c) Duplicate CONNECTION REQUEST and duplicate ACK.
5.2.3 Connection Release

Releasing a connection is more complex than establishing one, with two main approaches:
asymmetric release (one party disconnects unilaterally, potentially causing data loss) and
symmetric release (each side releases its connection independently). While symmetric
release is safer, it works best when each side knows when it's done sending data.
The Two-Army Problem demonstrates the difficulty in synchronizing disconnections, where
unreliable communication channels lead to uncertainty and failure. Despite attempts at
protocols like a three-way handshake, it's proven that no perfect protocol exists for
mutual synchronization.
To handle this, practical solutions include using timers and retransmission mechanisms to
manage disconnection. In cases of lost messages, timers prevent indefinite waiting, and
after a certain number of retries, the connection is released. However, this can lead to
half-open connections (where one side believes the connection is closed, but the other
side does not). This issue is resolved by introducing rules like automatic disconnection
after inactivity, avoiding the need for endless retries.
Ultimately, the transport layer alone cannot solve connection release issues, and application
layers must be involved. Web servers often use abrupt closures (asymmetric close) based
on their predictable data exchange patterns, while other scenarios require more careful
coordination between both sides to ensure proper termination.

Four protocol scenarios for releasing a connection. (a) Normal case of three-way handshake. (b) Final ACK
lost. (c) Response lost. (d) Response lost and subsequent DRs lost.
5.2.4 Error Control and Flow Control
In the transport layer, error control and flow control are key mechanisms that ensure reliable data
delivery and prevent congestion. These mechanisms are similar to those in the data link layer, but with
important differences in function and scope. Here's an overview:
Error Control
The transport layer error control uses mechanisms like checksums and retransmissions, similar to the link
layer. However, the transport layer checksum is end-to-end, meaning it protects data across the entire
path between sender and receiver, unlike the link layer's checks, which protect data only across individual
links. This is crucial because errors can occur in routers or other intermediate points, which would not be
detected by link-layer checks. This concept aligns with the end-to-end argument, which suggests that
certain types of error detection should be handled at the endpoints of a communication, rather than on
every intermediate link.
Flow Control
Flow control ensures that a fast sender does not overwhelm a slower receiver. At the transport layer, this
is typically achieved through a sliding window protocol. In scenarios with high bandwidth and long
delays (like TCP connections), the sender may need to manage a larger buffer window to prevent stalling
and maximize throughput. This dynamic buffer management can be adjusted based on the network's
capacity to handle the traffic, not just the receiver's buffer space. Buffer space may be allocated
dynamically, allowing the receiver to adjust its capacity as needed.
Buffer Management
Dynamic buffer allocation is a critical aspect, especially for high-bandwidth traffic. The sender requests
buffers from the receiver, and the receiver grants as many as it can handle. This approach helps to adjust
for variations in traffic and network conditions. In contrast to a fixed window size, where buffer space is
allocated statically, dynamic allocation allows for more flexibility. For instance, TCP uses a window size
field in its header to manage this.
Congestion Control
When buffer space is not the limiting factor, network congestion can become the bottleneck. Belsnes
(1975) proposed a dynamic sliding window mechanism to adapt the sender's window size based on the
network's carrying capacity. This helps in maintaining a balance between the sender's rate of transmission
and the network's ability to handle the traffic, preventing congestion and ensuring smooth data flow.
This approach is especially useful in wide-area networks, where the available bandwidth may fluctuate,
necessitating adjustments in the sender's transmission rate. TCP and other transport protocols implement
similar congestion control mechanisms, dynamically adjusting the window size based on network
conditions.
These techniques ensure that data is delivered reliably and efficiently while minimizing the risk of
congestion or buffer overflow.

(a) Chained fixed-size buffers. (b) Chained variable-sized buffers.

(c) One large circular buffer per connection.
5.2.5 Multiplexing
Multiplexing and inverse multiplexing are essential concepts in network communications,
particularly in the transport layer. These techniques allow multiple data streams or
connections to share network resources efficiently.
Multiplexing in the Transport Layer
Multiplexing refers to the method of using a single network connection to handle multiple
transport connections. In cases where a host only has one network address (like an IP
address), multiple transport-layer protocols (such as TCP or UDP) may need to share this
 address. When a segment arrives, the transport layer uses identifiers, like port numbers,
to determine which process (or application) should handle the incoming data. This
ensures that traffic for different applications is properly routed, even when using the
same network connection.
Example: A host with a single IP address may have several applications, such as a web server and
an email client, each using different transport layer connections. Each connection is
distinguished by a unique combination of IP address and port number.
Inverse Multiplexing
Inverse multiplexing, on the other hand, involves splitting a single transport connection across
multiple physical or virtual network paths to increase bandwidth or reliability. This can
be useful if a single network path doesn't provide enough capacity or redundancy for the
data transmission. In inverse multiplexing, data is distributed among several paths,
typically in a round-robin manner, to achieve higher throughput or better fault tolerance.
Example: The Stream Control Transmission Protocol (SCTP) is an example of a transport protocol
that supports inverse multiplexing. SCTP allows a single connection to be established over
multiple network interfaces, enabling more bandwidth and redundancy compared to TCP,
which uses a single network path.
At the link layer, inverse multiplexing can also be implemented by aggregating multiple low-
speed links to form a single, faster link, improving throughput and reliability.
These multiplexing and inverse multiplexing mechanisms help ensure efficient and scalable use of
network resources, improving the performance and reliability of network communication.

(a) Multiplexing. (b) Inverse multiplexing

5.2.6 Crash Recovery
The recovery from host crashes, particularly when long-lived connections are involved, presents
significant challenges in network protocols. In the transport layer, protocols like TCP and UDP
handle network and router crashes via retransmissions. However, recovering from host crashes is
more complex, especially for scenarios where connections may be long-lived, such as during large
file transfers.
Problem with Host Crashes
When a server crashes during data transmission, the server's state (such as segment
acknowledgment information) is lost. If the server recovers and requests clients to inform it of
the status of open connections, the client may face difficulties in deciding whether to retransmit a
segment. This difficulty arises from the fact that events like sending acknowledgments and
writing data to the application cannot happen simultaneously. Thus, when a crash happens after
one event but before the other, the client may incorrectly assume the segment was received (or
might retransmit unnecessarily), leading to missing or duplicate segments.
For example, consider a simple stop-and-wait protocol where a client sends a file to a server. If
the server crashes after sending an acknowledgment but before writing to the application, the
client will think the segment was received and be in state S0 (no segments outstanding), leading it
to skip retransmitting the segment. If the crash occurs after the write but before the
acknowledgment is sent, the client will retransmit the segment, which could lead to a duplicate.
Server and Client Strategies
There are several possible strategies for how clients and servers handle the crash recovery:
• Server Strategies: The server can be programmed to either acknowledge first or write to
the application first.
• Client Strategies: The client can either always retransmit, never retransmit, or
conditionally retransmit based on the state (S0 or S1).
However, these strategies often lead to failures in recovery. The client may incorrectly decide
whether to retransmit based on incomplete or erroneous information, leading to lost or duplicate
segments.
Event Sequences and Failures
The event sequences at the server, such as acknowledging (A), writing (W), and crashing (C), can
occur in several orders, and these sequences lead to different recovery behaviors. Some event
sequences cause the protocol to fail in specific client-server combinations. For instance, if the
server crashes after sending an acknowledgment but before the write, and the client is
programmed to always retransmit, the client will incorrectly send a duplicate segment.
General Conclusion
The key takeaway is that host crash recovery in transport protocols cannot be fully transparent to
higher layers. The problem lies in the lack of synchronization between events like
acknowledgment and writing to the application. Recovery from a crash in one layer (e.g., the
transport layer) typically requires assistance from a higher layer (e.g., the application layer),
which needs to retain sufficient state information to reconstruct where it left off.
This issue is a manifestation of the broader principle that recovery from a layer-N crash can only
be done by layer N+1, provided that higher layers have enough context to restore the
connection’s state. This insight points to the inherent challenges in achieving truly reliable end-
to-end acknowledgments, especially when they depend on complex, stateful operations at both
the transport and application layers.
For more details on this issue and its theoretical implications, you can refer to the work of Saltzer
et al. (1984), which discusses these topics in depth.
 Application layer
Introduction
DNS — The Domain Name System
Electronic Mail
WWW
Streaming Audio and Video

1) The application layer is the highest layer in the protocol suite.

2) The application layer provides services to the user.
3) 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.
4) Two application layers assume that there is an imaginary direct connection
through which they can send and receive messages.
5) The application layer is the only layer that provides services to the Internet user
6) The flexibility of the application layer allows new application protocols to be
easily added to the Internet.
7) Applications need their own protocols.
8) These applications are part of network protocol.

DNS(Domain name system)

Introduction
• The internet model that follow the client/server paradigm.
• The DNS is a supporting program that is used by other programs such as E-mail.
 • A user of a e-mail program may know the e-mail address of the recipient;
however, the IP protocol needs the IP address.
• The DNS client program sends a request to a DNS server to map the e-mail
address to the corresponding IP address.
• To identify the remote system/user, TCP/IP protocols use the IP address, which
uniquely identifies the connection of a host to the internet.
• However, people prefer to use names instead of numeric values.
• The DNS system that can map a name to an address (or) address to a name.

DNS service Architecture:

• When the internet was small, mapping was done by using a host file.[two
columns-names and address-host store it-update periodic]
• Today it is impossible, bcoz the host file would be too large and updating
problem.
• The solution is to maintain in one computer and allow centralized access[huge
traffic]
• Huge information divided into small parts today and stored different
computer.[host can contact the closest computer holding the needed
information.[method used by DNS]

Name space
• It is unambiguous, the name assigned to machines must be unique.
• Name space map each address to a unique name in two ways.
• Flat Name space
• Hierarchical Name Space.
Flat Name Space:
✓ A name in this space is a sequence of characters without structure.
✓ A name may (or) may not have a common section.[it has no meaning].
✓ It cannot be used in internet.[duplication].

Hierarchical Name Space

• Each name has several parts.
• The first part define the nature of the organization.
• The second part can define name of an organization.
• The third part can define departments in the organization, and so on.
• The central authority assigned only the first two part the name space the rest of
parts are assigned organization itself.
• The organization can add prefix(or) suffix to the name to define its host or
resource.
• The organization need not worry about the same name chosen by the other
management for their resource.

Domain Name Space

• When we have hierarchical name space, a domain name space to be designed.
• In that tree names are defined in an inverted-tree with one root at the top.
• The tree can have only 128 levels.
• Level 0(root) to level127
Label
• Each node in the tree has a label, which is a string with a maximum of 63 characters.
• The root label is a null string(empty).

Domain Name
• A full domain name is a sequence of labels separated by dots.
• The domain names are always read from the node up to the root.
• Finally, it end with null(root node)

Fully Qualified Domain Name

• A fully qualified domain name (FQDN) is the complete domain name for a specific
computer, or host, on the Internet.
• The FQDN consists of two parts: the hostname and the domain name.
• If the label is terminated by a null string(.), it is called a FQDN
• For example, an FQDN for a hypothetical mail server might be mymail.somecollege.edu.
• The hostname is mymail, and the host is located within the domain somecollege.edu.

Partially Qualified Domain Name(PQDN)

• If a label is not terminated by a NULL string, it is called a PQDN.
 • It starts from a node, but it does not reach the root.
• Here the resolver can supply the missing part, called the suffix, to create an FQDN.
• Example:
• Google
• Yahoo
• Annauniv
• Kct

Domain
• A domain is a subtree of the domain name space.
• The name of the domain is the domain name of the node at the top of the subtree.

Distribution of Name Servers

• The information contained in the domain name space must be stored.
• It is inefficient also unreliable[one computer store huge information.]

Hierarchy of Name Servers

 • The solution to these problems is to distribute the information among many computers
called DNS servers.
• We create many sub DNS server based on the requirement[each divided into sub
domain]

Zone and domain

• Segments of the DNS namespace managed by organizations or individuals.
• Includes information like DNS records.
• When a server dedicated for (responsible) over is called a zone.

Root server
• A root server is a server, whose zone consists of the whole tree.
• A root server usually does not store any information but authority to other servers.
Primary server and secondary servers
• DNS defines two types of servers:
• A primary server -stores a file about the zone, responsible for creating , maintaining,
and updating the zone file.
• A secondary server – that transfers the complete information about a zone from
another server and store the file on its local disk.

DNS in the Internet

• In the internet, the domain space(tree) is divided into three different section:
• Generic domains
• Country domains
• Inverse domains

Generic domains
• It define registered hosts according to their generic behaviour.
EMAIL (SMTP, MIME, IMAP, POP)
1. One of the most popular Internet services is electronic mail (E-mail).
2. Email is one of the oldest network applications.
 3. When the sender and the receiver of an e-mail are on the same system, we need only
two User Agents and no Message Transfer Agent
4. When the sender and the receiver of an e-mail are on different system, we need two UA,
two pairs of MTA (client and server), and two MAA (client and server).

The three main components of an Email are

1. User Agent (UA)
2. Message Transfer Agent (MTA) – SMTP
3. Message Access Agent (MAA) - IMAP , POP

1. When Alice needs to send a message to Bob, she runs a UA program to prepare the
message and send it to her mail server.
2. The mail server at her site uses a queue (spool) to store messages waiting to be sent.
3. The message, however, needs to be sent through the Internet from Alice’s site to Bob’s
site using an MTA.
4. Here two message transfer agents are needed: one client and one server.
5. The server needs to run all the time because it does not know when a client will ask for a
connection.
6. The client can be triggered by the system when there is a message in the queue to be
sent.
7. The user agent at the Bob site allows Bob to read the received message.
8. Bob later uses an MAA client to retrieve the message from an MAA server running on the
second server.
Command driven
1. Command driven user agents belong to the early days of electronic mail.
2. A command-driven user agent normally accepts a one character command from the
keyboard to perform its task.
3. Some examples of command driven user agents are mail, pine, and elm.

GUI-based
1. Modern user agents are GUI-based.
2. They allow the user to interact with the software by using both the keyboard and the
mouse.
3. They have graphical components such as icons, menu bars, and windows that make the
services easy to access.
4. Some examples of GUI-based user agents are Eudora and Outlook.
 Multipurpose Internet Mail Extension (MIME)
standard that extends the functionality of Internet email to support multimedia content such as
text in character sets other than ASCII, attachments, images, audio, and video. MIME is also used
in other Internet protocols like HTTP to define the type of content being transmitted.
Key Features of MIME
1. Content Type Identification:
o MIME identifies the type of content using MIME types (e.g., text/html,
image/jpeg).
2. Multimedia Support:
o Supports a wide range of content types beyond plain text, including images,
audio, video, and application data.
3. Encoding Binary Data:
o Allows binary data to be encoded into a format suitable for transport over text-
based protocols.
4. Email Attachments:
o Provides a way to include attachments in emails.
5. Multipart Messages:
o Enables the inclusion of multiple types of content in a single email, such as text
and images.
Multipurpose Internet Mail Extensions (MIME) is a standard that extends the functionality of
Internet email to support multimedia content such as text in character sets other than ASCII,
attachments, images, audio, and video. MIME is also used in other Internet protocols like HTTP
to define the type of content being transmitted.

Key Features of MIME

1. Content Type Identification:
o MIME identifies the type of content using MIME types (e.g., text/html,
image/jpeg).
2. Multimedia Support:
o Supports a wide range of content types beyond plain text, including images,
audio, video, and application data.
3. Encoding Binary Data:
o Allows binary data to be encoded into a format suitable for transport over text-
based protocols.
4. Email Attachments:
o Provides a way to include attachments in emails.
5. Multipart Messages:
o Enables the inclusion of multiple types of content in a single email, such as text
and images.
MIME Structure in Email
An email message using MIME consists of the following components:
1. Headers:
o MIME adds additional headers to the email:
▪ MIME-Version: Indicates the MIME version (e.g., 1.0).
▪ Content-Type: Specifies the media type (e.g., text/html).
▪ Content-Transfer-Encoding: Specifies the encoding method (e.g.,
base64).
2. Body:
o The actual content, which can include plain text, HTML, or attachments.
o May be divided into multiple parts.
MIME Types
MIME types define the nature and format of the content. Each type has two parts: a type and a
subtype.
Common MIME Types:
• Text:

o text/plain: Plain text.

o text/html: HTML content.
• Image:
o image/jpeg: JPEG images.
o image/png: PNG images.
• Audio:
o audio/mpeg: MP3 files.
o audio/ogg: OGG files.
• Video:
o video/mp4: MP4 videos.
o video/webm: WebM videos.
• Application:
o application/json: JSON data.
o application/pdf: PDF documents.
o application/zip: ZIP archives.
• Multipart:
 o multipart/mixed: A combination of different types.
o multipart/alternative: Alternative representations of the same content (e.g.,
plain text and HTML).
MIME in HTTP
MIME types are widely used in HTTP to specify the type of data being transferred:
• Content-Type Header: Indicates the MIME type of the resource.

o Example: Content-Type: text/html

Encoding Methods in MIME
MIME uses encoding methods to convert binary data into text format:
• Base64: Encodes binary data as ASCII characters.

• Quoted-Printable: Encodes special characters for text.

• 7bit: Ensures compatibility with older systems.
 WWW –World Wide Web
• WWW was constructed originally by a small group of people led by Tim Berners Lee at
CERN, in 1989 and in 1991 this was released to the world.
• WWW is a distributed client/server service, in which a client (Browsers such as IE,
Firefox, etc.) can access services at a server (Web server such as IIS, Apache).
• The service provided is distributed over many locations called sites.
• A new protocol for the Internet and a system of document access to use it was proposed
and named as WWW.
 • Web is a vast collection of data, information, software and protocols , spread across the
world in web servers, which are accessed by client machines by browsers through the
Internet.

• This system allows document search and retrieval from any part of the Internet.

• The documents were having Hypertext as the content

• The units of information on the web can be referred to as pages, documents or

resources.

• A document can contain text, images, sound and video, together called Hypermedia.

COMPONENTS OF THE WEB (WWW)

Structural Components
1. Web Clients/Web Browsers
2. Web Servers – run on sophisticated hardware
3. Internet – the global infrastructure which facilitates data transfer.
Semantic Components
1. Hyper Text Transfer Protocol (HTTP)
2. Hyper Text Markup Language (HTML)
3. eXtensible Markup Language (XML)
4. Uniform Resource Identifiers (URIs)

WEB CLIENTS (BROWSERS)

1. A browser is a software on the client on the web which initiates the communication with
the server.
2. Each browser usually consists of three parts: a controller, client protocols, and
interpreters.
3. 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.
4. Examples are Internet Explorer, Mozilla FireFox, Netscape Navigator, Safari etc.
WEB SERVERS
1. All the communication between the web client and a web server use the standard
protocol called as HTTP.
2. Web server informs its operating system to accept incoming network connections using
a specific port on the machine.
3. The server also runs as a background process.
4. A client (browser) opens a connection to the server, sends a request, receives
information from server and closes the connection.
5. Web server monitors a communications port on its host machine, accepts the http
commands through it and performs specified operations.
6. HTTP commands include a URL specifying the host machine.
7. The URL received is translated into either a filename or a program name, accordingly
the requested file or the output of the program execution is sent back to the browser.

Proxy Server
• A Proxy server is a computer that keeps copies of responses to recent requests.
1. The web client sends a request to the proxy server.
2. The proxy server checks its cache.
3. If the response is not stored in the cache, the proxy server sends the request to the
corresponding server.

1. Incoming responses are sent to the proxy server and stored for future requests from
other clients.
2. The proxy server reduces the load on the original server, decreases traffic, and improves
latency.
3. However, to use the proxy server, the client must be configured to access the proxy
instead of the target server.
4. The proxy server acts as both server and client.
5. When it receives a request from a client for which it has a response, it acts as a server
and sends the response to the client.
6. When it receives a request from a client for which it does not have a response, it first
acts as a client and sends a request to the target server.
7. When the response has been received, it acts again as a server and sends the response to
the client.
 Audio and Video Streaming
Audio File Features
• Audio file is a record of captured sound that can be played back
• e.g. .WAV File
• Audio files are compressed for storage or faster transmission
• Requires high bandwidth to transfer across the network
Audio Streaming Concept

Audio Streaming Concept

• Analog-to-Digital modulation
• Streaming audio technologies relies on:
→ Sound sequences
→ Compression schemes
• Compression schemes (encoding) decreases the audio’s bandwidth requirements:
 → Lowering the audio’s sampling rate
→ Filtering high frequencies
→ Performing other waveform
Audio Streaming Advantages
• Real time audio content.
• Low bandwidth media used.
• No waiting for downloading audio file.
• Internet users can enjoy a live online program.
Audio Streaming Applications
• Long-distance or automated training
• Seminars
• Concerts
• Speeches
• Music samples
• Online corporate messages
• Hear the news / Radio
Audio Formats
• Microsoft Windows Media Formats
• .avi, .asf, .asx, .rmi, .wav
• Moving Pictures Experts Group (MPEG)
• .mp3
• Musical Instrument Digital Interface (MIDI)
• .mid, .rmi
• Apple Quick Time, Macintosh AIFF Resource
• .qt, .aif, .aifc, .aiff, .mov
• UNIX Formats
• .au, .snd
Audio Streaming Products
• Window Media Technologies (Microsoft)
• RealSystem G2 (RealNetworks)
• Shockwave Streaming Audio (Macromedia)
• IBM Bamba (IBM)
• Streamworks (Xing Technology)
 • Media Player (Netscape)

Video Streaming
• The object is to overcome the negative effects of physical distance and network
technology limitation.

Streaming Advantages
• Reduce setup time
• Reduction in client storage requirement
• Video can be viewed in real time
• Transmission signals over low bandwidth facilities
Video Streaming Architecture
• Content Creation/Capture
• Content Management
• Content Formatting (Compression)
• Delivery
• Distribution
• Presentation (Viewing)
• View Control
Video Capture
• Converting analog to video signals
• A special video capture card to convert the analog signals to digital form and
compresses the data.
• Also digital video devices that can capture images and transfer to a computer
Content Management
• Critical in video server
• The purpose including create, collect, catalog, organize, store, and access to massive
multimedia information database
Video Input Formats
• AVI
• ActiveMovie
• Cinepak
• Indeo
• motion-JPEG
• MPEG
• QuickTime
• RealVideo
• Video for Windows
• XGA