Module 1
Module 1
Module 1
Application Layer: Principles of Network Applications: Network Application Architectures,
Processes Communicating, Transport Services Available to Applications, Transport Services
Provided by the Internet, Application-Layer Protocols. The Web and HTTP: Overview of HTTP,
Non-persistent and Persistent Connections, HTTP Message Format, User-Server Interaction:
Cookies, Web Caching, The Conditional GET, File Transfer: FTP Commands & Replies, Electronic
Mail in the Internet: SMTP, Comparison with HTTP, Mail Message Format, Mail Access Protocols,
DNS; The Internet's Directory Service: Services Provided by DNS, Overview of How DNS Works,
DNS Records and Messages, Peer-to-Peer Applications: P2P File Distribution, Distributed Hash
Tables, Socket Programming: creating Network Applications: Socket Programming with UDP,
Socket Programming with TCP.
2.1 Principles of Network
Applications
Network-applications are the driving forces for the explosive
development of the internet.
• Examples of network-applications:
1) Web
3) File transfers
5) E-mail
•The possible services that a transport layer can offer to application layer can be
broadly classified into four dimensions
• Reliable Data Transfer
• Throughput
• Timing
• Security
Reliable Data Transfer
• Packets can get lost within a computer network.
• For example, a packet can overflow a buffer in a router, or can be discarded by a host or router
after having some of its bits corrupted.
• For many applications—such as electronic mail, file transfer, remote host access, Web document
transfers, and financial applications—data loss can have devastating consequences.
• Thus, to support these applications, something has to be done to guarantee that the data sent by
one end of the application is delivered correctly and completely to the other end of the application.
Throughput
• Transport-layer protocol could provide guaranteed available throughput at some specified rate.
• With such a service, the application could request a guaranteed throughput of r bits/sec, and the
transport protocol would then ensure that the available throughput is always at least r bits/sec.
• Such a guaranteed throughput service would appeal to many applications.
• For example, if an Internet telephony application encodes voice at 32 kbps, it needs to send data
into the network and have data delivered to the receiving application at this rate.
Timing
• A transport-layer protocol can also provide timing guarantees.
• Interactive real-time applications, such as Internet telephony, virtual environments,
teleconferencing, and multiplayer games require tight timing constraints on data delivery
in order to be effective.
Security
• Transport protocol can provide an application with one or more security services.
• For example, in the sending host, a transport protocol can encrypt all data transmitted by the
sending process, and in the receiving host, the transport-layer protocol can decrypt the data
before delivering the data to the receiving process.
• A transport protocol can provide security services like confidentiality, data integrity and endpoint
authentication
Transport Services Provided by the Internet
• The Internet makes two transport protocols available to applications, UDP and TCP
persistent HTTP
• multiple objects can be sent over single TCP connection between client, server
Non-persistent HTTP
Non-persistent HTTP (cont.)
Non-persistent HTTP: response time
RTT (definition): time for a small packet to travel from
client to server and back
HTTP response time:
• one RTT to initiate TCP connection
• one RTT for HTTP request and first few bytes of HTTP
response to return
• file transmission time
• non-persistent HTTP response time =
2RTT+ file transmission time
Persistent HTTP
non-persistent HTTP issues:
• OS overhead for each TCP connection
• requires 2 RTTs per object
persistent HTTP:
• server leaves connection open after sending response
• subsequent HTTP messages between same client/server sent over open
connection
• client sends requests as soon as it encounters a referenced object
• as little as one RTT for all the referenced objects
HTTP request message
HTTP request message: general format
Method types
HTTP/1.0:
• GET
• POST
• HEAD
• asks server to leave requested object out of response
HTTP/1.1:
• GET, POST, HEAD
• PUT
• uploads file in entity body to path specified in URL field
• DELETE
• deletes file specified in the URL field
Uploading form input
POST method:
• web page often includes form input
• input is uploaded to server in entity body
URL method:
• uses GET method
• input is uploaded in URL field of request line:
www.somesite.com/animalsearch?monkeys&banana
HTTP response message
General Format of HTTP response message
HTTP response status codes
• status code appears in 1st line in server-to-client response message.
• some sample codes:
200 OK
• request succeeded, requested object later in this msg
301 Moved Permanently
• requested object moved, new location specified later in this msg (Location:)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Trying out HTTP (client side) for yourself
User-server state: cookies
many Web sites use cookies
four components:
1) cookie header line of HTTP response message
2) cookie header line in next HTTP request message
3) cookie file kept on user’s host, managed by user’s browser
4) back-end database at Web site
example:
• Susan always access Internet from PC
• visits specific e-commerce site for first time
• when initial HTTP requests arrives at site, site creates:
• unique ID
• entry in backend database for ID
Cookies: keeping “state”
client server
ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action
client origin
server
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
Mail message format
SMTP: protocol for
exchanging email msgs header
blank
RFC 822: standard for text line
message format:
• header lines, e.g.,
• To: body
• From:
• Subject:
different from SMTP MAIL
FROM, RCPT TO:
commands!
• Body: the “message”
• ASCII characters only
Application Layer 2-53
Mail access protocols
user
mail user
SMTP SMTP access
agent agent
protocol
(e.g., POP,
IMAP)
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
DNS: The Internet’s Directory Service
• people: many identifiers:
• SSN, name, passport #
• Internet hosts, routers:
• hostnames, e.g., www.yahoo.com,www.eurecom.fr - used by humans
• IP address (32 bit) – ex 121.7.104.83
Q: how to map between IP address and name, and vice versa ?
… …
2
• host at cis.poly.edu wants 3
TLD DNS server
IP address for 4
gaia.cs.umass.edu
5
gaia.cs.umass.edu
root DNS server
DNS name resolution example
2 3
7
recursive query: 6
puts burden of name TLD DNS
server
resolution on
contacted name local DNS server
server dns.poly.edu 5 4
1 8
gaia.cs.umass.edu
DNS: caching, updating records
• once (any) name server learns mapping, it caches mapping
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
• thus root name servers not often visited
• cached entries may be out-of-date (best effort name-to-
address translation!)
• if name host changes IP address, may not be known Internet-wide
until all TTLs expire
Department of Computer Science & Engineering
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
DNS records and messages
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)
type=A type=CNAME
name is hostname name is alias name for some
value is IP address “canonical” (the real) name
Example: (relay1.foo.com, www.ibm.com is really
145.37.93.126, A) servereast.backup2.ibm.com
type=NS value is canonical name
• name is domain (e.g.,
foo.com) type=MX
• value is hostname of value is name of
authoritative name mailserver associated with
server for this domain name
DNS protocol, messages
• query and reply messages, both with same message format
2 bytes 2 bytes
identification flags
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
Pure P2P architecture
• no always-on server
• arbitrary end systems
directly communicate
• peers are intermittently
connected and change IP
addresses
examples:
• file distribution
(BitTorrent)
• Streaming (KanKan)
• VoIP (Skype)
increases linearly in N
Application Layer 2-78
File distribution time: P2P
• server transmission: must
upload at least one copy F
us
• time to send one copy: F/us
di
client: each client must network
download file copy ui
min client download time:
F/dmin as aggregate must download NF
clients:
bits
max upload rate (limting max download
timerate) is us + S
to distribute Fui
DP2P
to N clients using > max{F/us,,F/dmin,,NF/(us + Sui)}
P2P approach
increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 2-79
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
1.5
0.5
0
0 5 10 15 20 25 30 35
N
Application Layer 2-80
P2P file distribution: BitTorrent
file divided into 256Kb chunks
peers in torrent send/receive file chunks
Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent
• DHT paradigm
• Peer churn
Department of Computer Science & Engineering
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
Simple Database
Simple database with(key, value) pairs:
• key: social security #; value: human
nameValue Key
John Washington 132-54-3570
Diana Louise Jones 761-55-3791
Xiaoming Liu 385-41-0902
Rakesh Gopal 441-89-1956
Linda Cohen 217-66-5609
……. ………
Lisa Kobayashi 177-23-0199
3
15
4
12
5
10
8 “overlay network”
Resolving a query
4
12
O(N) messages 5
on avgerage to resolve
query, when there 10
8
are N peers
Circular DHT with shortcuts
1 What is the value for
value key 11
3
15
4
12
5
10
8
• each peer keeps track of IP addresses of predecessor, successor,
short cuts.
• Reduces the number of messages.
• possible to design shortcuts with O(log N) neighbors, O(log N)
messages in query
Peer churn handling peer churn:
1 peers may come and go
(churn)
15 3 each peer knows address
of its two successors
each peer periodically
4
pings its
12 two successors to check
5
aliveness
10 if immediate successor
8 leaves, choose next
example: peer 5 abruptly leaves
successor as new
immediate successor
Peer churn handling peer churn:
1 peers may come and go
(churn)
15 3 each peer knows address
of its two successors
each peer periodically
4
pings its
12 two successors to check
aliveness
10 if immediate successor
8 leaves, choose next
example: peer 5 abruptly leaves
successor as new
•peer 4 detects peer 5’s departure; makes 8successor
immediate its immediate
successor
• 4 asks 8 who its immediate successor is; makes 8’s
immediate successor its second successor.
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-end-
transport protocol
application application
socket controlled by
process process app developer
transport transport
network network controlled
link
by OS
link Internet
physical physical
Module – 1
APPLICATION LAYER
Sneha N P
Assistant
Professor
Dept. of CSE,
ATMECE,Mysore
Socket programming
Two socket types for two transport services:
• UDP: unreliable datagram
• TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters (data)
from its keyboard and sends the data to
the server.
2. The server receives the data and
converts characters to uppercase.
3. The server sends the modified data to
the client.
4. The client receives the modified data
Socket programming with
UDP
UDP: no “connection” between client & server
• no handshaking before sending data
• sender explicitly attaches IP destination address and
port # to each packet
• rcvr extracts sender IP address and port# from received
packet
UDP: transmitted data may be lost or received
out-of-order
Application viewpoint:
• UDP provides unreliable transfer of groups of bytes
(“datagrams”) between client and server
Application Layer
Client/server socket interaction:
UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket
write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket
Example app: UDP client
Python UDPClient
include Python’s socket
library from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(socket.AF_INET,
server
write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
Example app: TCP client
Python TCPClient
from socket import *
serverName = ’servername’
create TCP socket for serverPort = 12000
server, remote port 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
No need to attach server clientSocket.send(sentence)
name, port
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()
Example app: TCP server
Python TCPServer
from socket import *
create TCP welcoming
serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
server begins listening for
incoming TCP requests
serverSocket.listen(1)
print ‘The server is ready to receive’
loop forever while 1:
server waits on accept() connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
sentence = connectionSocket.recv(1024)
read bytes from socket (but
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this
connectionSocket.send(capitalizedSentence)
client (but not welcoming connectionSocket.close()
socket)
Chapter 2:
summary
our study of network apps now complete!
• application architectures specific protocols:
• client-server HTTP
• P2P FTP
• application service SMTP, POP, IMAP
requirements:
DNS
• reliability, bandwidth, delay
P2P: BitTorrent,
• Internet transport service model
DHT
• connection-oriented,
reliable: TCP
socket programming:
• unreliable, datagrams: UDP TCP, UDP sockets