Application Layer: Goals

Application Layer
Goals: ❒ learn about protocols

❒ conceptual and
by examining popular
implementation application-layer
aspects of application- protocols
layer protocols ❍ dns
❍ client-server ❍ ftp
paradigm ❍ http
❍ peer-peer paradigm ❍ smtp/pop3
❍ transport layer
service models
❍ sockets API
2a: Application Layer 1

1/19/05 (SSL)
Some network apps

❒ E-mail ❒ Internet telephone
❒ Web ❒ Real-time video
❒ Instant messaging conference
❒ Remote login ❒ Massive parallel
❒ P2P file sharing

computing
❒ Multi-user network
games
❒ Streaming stored
video clips

1/19/05 (SSL)
1
Creating a network app
Write programs that application
transport
run on different end

network
❍ data link
systems and
physical
❍ communicate over a
network
❍ e.g., Web: server software
communicates with browser
software
No software written for application
application
devices in network core
transport
transport network
network data link
Network core devices do
data link physical
❍ physical
not function at app layer

❍ This design allows for
rapid app development
1/19/05 (SSL)
Client-server architecture
server:
❍ always-on host
❍ permanent IP address
❍ server farms for scaling
clients:
❍ communicate with
server (speak first)
❍ may be intermittently
connected
❍ may have dynamic IP
addresses
❍ do not communicate
directly with each other

1/19/05 (SSL)
2
Pure P2P architecture
❒ no always-on server
❒ arbitrary end systems
directly communicate
❒ peers are intermittently
connected and may
change IP addresses
❒ example: Gnutella
Highly scalable
but difficult to manage

1/19/05 (SSL)
Hybrid of client-server and P2P

Napster
❍ File transfer P2P
❍ File search centralized:
• Peers register content at central server
• Peers query central server to locate content
Instant messaging
❍ Chatting between two users is P2P
❍ Presence detection/location info centralized:
• User registers its IP address with central server
when it comes online
• User contacts central server to find IP addresses of
buddies

1/19/05 (SSL)
3
Processes communicating
Process: program running Client process: process
within a host that initiates
❒ within same host, two communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS)
❒ processes in different ❒ Note: applications in
hosts communicate by both client-server and
exchanging messages P2P architectures have
(of an application-layer client & server
protocol) processes
1/19/05 (SSL)
How to address processes

❒ For a process to ❒ Identifier includes
receive messages, it both the IP address
must have an identifier and port number
❒ A host has a unique 32- associated with the
bit IP address process on the host.
❒ Q: Is the IP address of ❒ Example of well-known
the host on which the port numbers:
process runs sufficient ❍ HTTP server: 80
for identifying the ❍ Mail server: 25
process? ❒ More on this later
❒ Answer: No, many
processes can be
running on same host
1/19/05 (SSL)
4
Application and application-layer protocol
Application: communicating
processes application
transport
❍ running in different hosts network
data link
❍ exchange messages to
physical
implement app
❍ e.g., email, file transfer,
Web
Application-layer protocol
❍ one “piece” of an app
❍ defines messages application
application
exchanged by app and transport
transport
network
network
actions taken data link
data link
physical
physical
❍ delivery service provided
by lower layer protocols

1/19/05 (SSL)
App-layer protocol defines

❒ Types of messages ❒ Rules for when and
exchanged, eg, request how processes send &
& response messages respond to messages
❒ Syntax of message
types: what fields in
messages & how fields Public-domain protocols:
are delineated ❍ defined in RFCs
❍ allows for
❒ Semantics of the interoperability
fields, ie, meaning of ❍ eg, HTTP, SMTP
information in fields Proprietary protocols:
❍ eg, KaZaA

1/19/05 (SSL)
5
What transport service does an app need?
Data loss Bandwidth
❒ some apps (e.g., audio) can ❒ some apps (e.g.,
tolerate some loss multimedia) require
❒ other apps (e.g., file minimum amount of
transfer, telnet) require bandwidth to be
100% reliable data
“effective”
transfer
❒ other apps (“elastic
Timing apps”) make use of
❒ some apps (e.g., whatever bandwidth
Internet telephony, they get
interactive games)
require low delay to be
“effective”
1/19/05 (SSL)
Transport service requirements of common apps
Application Data loss Bandwidth Time Sensitive
file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100s msec
instant messaging no loss elastic yes and no

1/19/05 (SSL)
6
Services provided by Internet
transport protocols
TCP service: UDP service:
❒ connection-oriented: setup ❒ unreliable data transfer
required between client, between sending and
server receiving users
❒ reliable transport between ❒ does not provide
sending and receiving users
connection setup,
❒ flow control: sender won’t reliability, flow control,
overwhelm receiver
congestion control, delay,
❒ congestion control: sender or bandwidth guarantee
throttled when network
overloaded
❒ does not provide delay, Q: why bother? Why is
minimum bandwidth there a UDP?
guarantees

1/19/05 (SSL)
Internet apps: their protocols and transport

protocols
Application Underlying
Application layer protocol transport protocol
e-mail smtp [RFC 2821] TCP

remote terminal access telnet [RFC 854] TCP
Web http [RFC 2616] TCP
file transfer ftp [RFC 959] TCP
network management SNMP UDP
name service dns UDP
streaming multimedia often proprietary UDP or TCP
(e.g., RealNetworks)
remote file server NFS UDP or TCP
Internet telephony often proprietary typically UDP
(e.g., Net2phone)

1/19/05 (SSL)
7
Socket programming
Goal: learn how to write client and server programs
which communicate by sending data into sockets,
reading data out of sockets
Socket API
❒ introduced in BSD4.1 UNIX, 1981
❒ sockets are explicitly created, used, then released by
applications
❒ client/server paradigm
❒ API: choice of a transport protocol and ability to
specify a few parameters
❍ unreliable datagram
❍ reliable byte stream

1/19/05 (SSL)
Sockets
A socket is like a door between application process
and end-end transport protocol (TCP or UDP)
controlled by
controlled by process application
application process
developer
developer socket socket
TCP with TCP with controlled by
controlled by
buffers, operating
operating buffers, internet system
system variables variables
host or host or
server server

1/19/05 (SSL)
8
Socket programming with TCP
Client must contact server ❒ When client makes connect
❒ server process must first call, client TCP establishes
be running connection to server TCP
❒ server must have created ❒ When contacted by a new
socket (door) that client, server creates new
welcomes client’s contact socket for server process to
communicate with the client
Client contacts server by:
❍ allows server to talk with
❒ creating client-local TCP
multiple clients
socket
❒ specifying IP address, port application viewpoint
number of server process
for connect call TCP provides reliable, in-order
transfer of byte stream
between client and server

1/19/05 (SSL)
Socket API for TCP (BSD Unix)

❒ Client side ❒ Server side
❍ socket(), returns client ❍ socket(), returns server
socket id socket id
❍ connect(), need to ❍ bind(), binds server
specify server IP address socket to server IP
and port, sends conn req address and port
❍ send(), sends to client ❍ listen(), willing to accept
socket conn req on server socket
❍ recv(), receives from ❍ accept(), accepts new
client socket conn req and returns its
connection socket id
❍ close(), closes connection
❍ recv(), receives from
connection socket
❒ note: OS supplies local IP address
and port for client ❍ send(), sends to
❒ Note: In Java, there is no explicit connection socket
connect call, etc. ❍ close(), closes connection
1/19/05 (SSL)
9
TCP Client/server interaction (in Java)
Server (running on hostid) Client
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
TCP create socket,

wait for incoming
connection request connection setup connect to hostid, port=x
connectionSocket = clientSocket =
welcomeSocket.accept() Socket()
send request using

read request from clientSocket
connectionSocket
write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
1/19/05 (SSL)
Socket programming with UDP
UDP: no “connection” between

client and server
❒ no handshaking in TCP
❒ sender explicitly provides application viewpoint
IP address and port of
destination for each UDP provides unreliable transfer
datagram of a group of bytes (datagram)
between client and server
❒ server must extract IP
address, port of sender
from received datagram
UDP: transmitted data may be
received out of order, or
lost

1/19/05 (SSL)
10
Socket API for UDP (BSD Unix)
❒ Client side ❒ Server side
❍ socket(), returns client ❍ socket(), returns server
socket id socket id
❍ sendto(), sends to client ❍ bind(), binds server
socket, need to specify socket to server IP
destination’s IP address address and port
and port ❍ recvfrom(), receives
❍ recvfrom(), receives from server socket: data
from client socket: data and sender’s IP address
and sender’s IP address and port
and port ❍ sendto(), sends to server
❍ bind(), optional socket, need to specify
❒ note: needs timeout management; destination’s IP address
OS supplies local IP address and and port
port for client if bind() not used

1/19/05 (SSL)
UDP Client/server interaction (in Java)

Server (running on hostid) Client
create socket, create socket,

port=x, for clientSocket =
incoming request: DatagramSocket()
serverSocket =
DatagramSocket()
Create, address (hostid, port=x)
send datagram request
using clientSocket
read request from
serverSocket
write reply to
serverSocket
specifying client read reply from
host address, clientSocket
port number close
clientSocket

1/19/05 (SSL)
11
DNS: Domain Name System
People: many identifiers:
❍ SSN, name, passport # Domain Name System:
Internet hosts, routers: ❒ distributed database
implemented in hierarchy of
❍ IP address (32 bit)
many name servers
- used for addressing
datagrams
❒ application-layer protocol
used to resolve names
❍ “name”, e.g., (address/name translation)
www.yahoo.com - used ❍ note: core Internet
by humans function, implemented as
Required: map between application-layer protocol
name and IP addresses ❍ complexity at network’s
“edge”

1/19/05 (SSL)
DNS
DNS services Why not centralize DNS?
❒ Hostname to IP ❒ single point of failure
address translation ❒ traffic volume
❒ Host aliasing ❒ distant centralized
❍ Canonical and alias database
names ❒ maintenance
❒ Mail server aliasing
❒ Load distribution
doesn’t scale!
❍ Replicated Web
servers: set of IP
addresses for one
canonical name

1/19/05 (SSL)
12
Distributed, Hierarchical Database
Root DNS Servers
com DNS servers org DNS servers edu DNS servers
pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS servers DNS servers
DNS servers DNS servers
Client wants IP address for www.amazon.com; 1st approx:

❒ Client queries a root server to find com DNS server
❒ Client queries com DNS server to get amazon.com
DNS server
❒ Client queries amazon.com DNS server to get IP
address for www.amazon.com
1/19/05 (SSL)
DNS: Root name servers

❒ contacted by local name server that cannot resolve name
❒ root name server:
❍ contacts authoritative name server if name mapping not known
❍ gets mapping
❍ returns mapping to local name server
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
k RIPE London (also Amsterdam, Frankfurt)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3
j Verisign, ( 11 locations) other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)
13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

1/19/05 (SSL)
13
TLD and Authoritative Servers
❒ Top-level domain (TLD) servers: responsible
for com, org, net, edu, etc, and all top-level
country domains uk, fr, ca, jp.
❍ Verisign maintains servers for com TLD
❍ Educause for edu TLD
❒ Authoritative DNS servers: organization’s

DNS servers, providing authoritative
hostname to IP mappings for organization’s
servers (e.g., Web and mail).
❍ Can be maintained by organization or service
provider

1/19/05 (SSL)
Local Name Server

❒ Does not strictly belong to hierarchy
❒ Each ISP (residential ISP, company,
university) has one.
❍ Also called “default name server”
❒ When a host makes a DNS query, query is
sent to its local DNS server
❍ Acts as a proxy, forwards query into hierarchy.

1/19/05 (SSL)
14
Example root DNS server
2
❒ Host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
gaia.cs.umass.edu
5
local DNS server

dns.poly.edu
7 6
1 8
authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu

1/19/05 (SSL)
Recursive queries root DNS server
recursive query:
2 3
❒ puts burden of name
resolution on 6
7
contacted name TLD DNS serve
server
❒ heavy load?
local DNS server
4
iterated query: dns.poly.edu 5
❒ contacted server 1 8
replies with name of
server to contact authoritative DNS server
❒ “I don’t know this dns.cs.umass.edu
requesting host
name, but ask this cis.poly.edu
server”
gaia.cs.umass.edu
1/19/05 (SSL)
15
DNS: caching and updating records
❒ once (any) name server learns mapping, it caches
mapping
❍ cache entries timeout (disappear) after some
time
❍ TLD servers typically cached in local name
servers
• Thus root name servers not often visited
❒ update/notify mechanisms under design by IETF
❍ RFC 2136
❍ http://www.ietf.org/html.charters/dnsind-charter.html

1/19/05 (SSL)
DNS records
DNS: distributed database of 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 “cannonical” (the real) name
e.g., www.ibm.com is really
❒ Type=NS
servereast.backup2.ibm.com
❍ name is domain (e.g.
❍ value is cannonical name
foo.com)
❍ value is host name of ❒ Type=MX
name server for this
❍ value is host name of
domain
mailserver associated with
name
1/19/05 (SSL)
16
DNS protocol, messages
DNS protocol : query and reply messages, both with
same message format
msg header
❒ identification: 16 bit #
for query, reply to query
has same #
❒ flags:
❍ query or reply
❍ recursion desired
❍ recursion available
❍ reply is authoritative

1/19/05 (SSL)
DNS protocol, messages
Name, type fields

for a query
RRs in reponse
to query
records for
authoritative servers
additional “helpful”
info that may be used

1/19/05 (SSL)
17
Inserting records into DNS
❒ Example: just created startup “Network Utopia”
❒ Register name networkutopia.com at a registrar (e.g.,
Network Solutions)
❍ Need to provide registrar with names and IP addresses of
your authoritative name servers (primary and secondary)
❍ Registrar inserts two RRs for each server into the com TLD
server:
(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)
❒ Put in authoritative server Type A record for

www.networkutopia.com and Type MX record for
networkutopia.com
❒ How do people get the IP address of your Web site?

1/19/05 (SSL)
ftp: the file transfer protocol
FTP file transfer

FTP FTP
user client server
interface
user
at host local file remote file
system system
❒ transfer file to/from remote host

❒ client/server model
client: side that initiates transfer (either to/from
❍
remote)
❍ server: remote host
❒ ftp: RFC 959
❒ ftp server: port 21

1/19/05 (SSL)
18
FTP: separate control, data connections
TCP control connection
❒ FTP client contacts FTP port 21
server at port 21, specifying
TCP as transport protocol
Client obtains authorization TCP data connection
❒ FTP port 20 FTP
over control connection client server
❒ Client browses remote
directory by sending ❒ Server opens a second TCP
commands over control data connection to transfer
connection.
another file.
❒ When server receives a
command for a file transfer, ❒ Control connection: “out of
the server opens a TCP data band”
connection to client ❒ FTP server maintains “state”:
❒ After transferring one file, current directory, earlier
server closes connection. authentication

1/19/05 (SSL)
ftp commands, responses
Sample commands: Sample return codes

❒ sent as ASCII text over ❒ status code and phrase (as
control channel in http)
❒ USER username ❒ 331 Username OK,
❒ PASS password password required
❒ 125 data connection
❒ LIST return list of file in
already open;
current directory
transfer starting
❒ RETR filename retrieves ❒ 425 Can’t open data
(gets) file connection
❒ STOR filename stores ❒ 452 Error writing
(puts) file onto remote file
host

1/19/05 (SSL)
19
Web and HTTP
First some jargon
❒ Web page consists of objects
❒ Object can be HTML file, JPEG image, Java
applet, audio file,…
❒ Web page consists of base HTML file which
includes several referenced objects
❒ Each object is addressable by a URL
❒ Example URL:
www.someschool.edu/someDept/pic.gif
host name path name

1/19/05 (SSL)
WWW: the http protocol
http: hypertext transfer

protocol htt
pr
eq u
❒ client/server model PC running htt es t
pr
Explorer esp
❍ client: browser that ons
e
requests, receives,
“displays” WWW
st
objects ue
eq Web Server
pr nse
❍ server: WWW server htt po
re s
sends objects in tp
ht
response to requests
❒ http1.0: RFC 1945
Mac running
❒ http1.1: RFC 2068 (old), Navigator
RFC 2616 (new)
❒ companion spec, HTML
1/19/05 (SSL)
20
The http protocol: more
Uses TCP service: http is “stateless”
❒ client initiates TCP ❒ server maintains no
connection (creates socket) information about
to server, port 80 past client requests
❒ server accepts TCP
connection from client aside
Protocols that maintain
❒ http protocol messages “state” are complex
exchanged between browser ❒ if server or client crashes,
(http client) and WWW their views of “state” may
server (http server) be inconsistent, must be
❒ TCP connection closed reconciled

1/19/05 (SSL)
HTTP connections
Nonpersistent HTTP Persistent HTTP
❒ At most one object is ❒ Multiple objects can
sent over a TCP be sent over single
connection. TCP connection
❒ HTTP/1.0 uses between client and
nonpersistent HTTP server.
❒ HTTP/1.1 uses
persistent connections
in default mode

1/19/05 (SSL)
21
Nonpersistent HTTP
(contains text,
Suppose user enters URL references to 10
www.someSchool.edu/someDepartment/home.index jpeg images)
1a. HTTP client initiates TCP

connection to HTTP server
1b. HTTP server at host
(process) at
www.someSchool.edu waiting
www.someSchool.edu on port 80
for TCP connection at port 80.
“accepts” connection, notifying
client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request
socket. Message indicates message, forms response
that client wants object message containing requested
someDepartment/home.index object, and sends message
into its socket
time
1/19/05 (SSL)
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects

1/19/05 (SSL)
22
Response time modeling
Definition of RRT: time to send
a small packet to travel from
client to server and back.
Response time:
initiate TCP
❒ one RTT to initiate TCP connection
connection RTT
❒ one RTT for HTTP request request
and first few bytes of HTTP file
time to
response to return RTT
transmit
❒ file transmission time file
file
total = 2RTT+transmit time received
time time

1/19/05 (SSL)
Persistent HTTP
Nonpersistent HTTP issues: Persistent without pipelining:

❒ requires 2 additional RTTs ❒ client issues new request
per object only when previous
❒ but most browsers open response has been received
parallel TCP connections to ❒ one additional RTT for
fetch referenced objects each referenced object
❒ OS must work and allocate Persistent with pipelining:
host resources for each TCP ❒ default in HTTP/1.1
connection ❒ client sends new request as
Persistent HTTP soon as it encounters a
❒ server leaves connection referenced object
open after sending response ❒ as little as one RTT for all
❒ subsequent HTTP messages of the referenced objects
between same client/server (plus transmission time)
are sent over connection

1/19/05 (SSL)
23
HTTP request message
❒ two types of HTTP messages: request, response

❒ HTTP request message:
❍ ASCII (human-readable format)
request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed (extra carriage return, line feed)
indicates end
of message
1/19/05 (SSL)
http request message: general format

1/19/05 (SSL)
24
Uploading form input
Post method:
❒ Web page often
includes form input URL method:
❒ Input is uploaded to ❒ Uses GET method
server in entity body ❒ Input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana

1/19/05 (SSL)
Method types
HTTP/1.0 HTTP/1.1
❒ GET ❒ GET, POST, HEAD
❒ POST ❒ PUT
❒ HEAD ❍ uploads file in entity
body to path specified
❍ asks server to leave
in URL field
requested object out of
response ❒ DELETE
❍ deletes file specified in
the URL field

1/19/05 (SSL)
25
http message format: reply
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html
data, e.g., data data data data data ...

requested
html file

1/19/05 (SSL)
http reply status codes

In first line in server->client response message.
A few sample codes:
200 OK
❍ request succeeded, requested object in this message
301 Moved Permanently
❍ requested object moved, new location specified later in
this message (Location:)
400 Bad Request
❍ request message not understood by server
404 Not Found
❍ requested document not found on this server
505 HTTP Version Not Supported
1/19/05 (SSL)
26
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu
2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1 By typing this in (hit carriage
Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server
3. Look at response message sent by HTTP server!

1/19/05 (SSL)
Cookies: keeping “state”

Many major Web sites Example:
use cookies ❍ Susan access Internet
Four components: always from same PC
❍ She visits a specific e-
1) cookie header line in
commerce site for first
the HTTP response
time
message
❍ When initial HTTP
2) cookie header line in
request arrives at site,
HTTP request message
site creates a unique ID
3) cookie file kept on and creates an entry in
user’s host and managed backend database for
by user’s browser ID
4) back-end database at
Web site

1/19/05 (SSL)
27
Cookies: keeping “state” (cont.)
client server
Cookie file usual http request msg server n e
da try i
tab n b
usual http response + creates ID as ac
e ke
ebay: 8734 Set-cookie: 1678 1678 for user nd
Cookie file
usual http request msg
amazon: 1678 cookie: 1678 cookie-
ss
ebay: 8734 specific acce
usual http response msg action
one week later:
ss
ce
ac
usual http request msg
Cookie file cookie-
cookie: 1678
amazon: 1678 spectific
ebay: 8734 usual http response msg action

1/19/05 (SSL)
Cookies (continued)
aside
What cookies can bring: Cookies and privacy:
❒ authorization ❒ cookies permit sites to
❒ shopping carts
learn a lot about you
❒ you may supply name
❒ recommendations
and e-mail to sites
❒ user session state
(Web e-mail)
❒ advertising companies
obtain info across
sites

1/19/05 (SSL)
28
Web caches (proxy server)
Goal: satisfy client request without involving origin server
❒ user sets browser: Web origin

accesses via cache server
❒ browser sends all HTTP HT Proxy

t
requests to cache T Pr server ues
eq u re q
if object in cache, cache clientHTTP est
HT
T P
o ns
e
❍ r es
pon r esp
returns object se TP
HT
else cache requests est
u
req
❍
object from origin TP n se
HT po
server, then returns r es
TP
object to client HT
client
origin
server

1/19/05 (SSL)
More about Web caching

❒ Cache acts as both client Why Web caching?
and server ❒ Reduce response time for
❒ Typically cache is installed client request.
by ISP (university, ❒ Reduce traffic on an
company, residential ISP) institution’s access link.
❒ Internet dense with caches
enables “poor” content
providers to effectively
deliver content (but so
does P2P file sharing)

1/19/05 (SSL)
29
Caching example
origin
Assumptions
servers
❒ average object size = 100,000
bits public
Internet
❒ avg. request rate from
institution’s browsers to origin
servers = 15/sec
1.5 Mbps
❒ delay from institutional router
access link
to any origin server and back
to router = 2 sec institutional
network
10 Mbps LAN
Consequences
❒ utilization on LAN = 15%
❒ utilization on access link = 100%
❒ total delay = Internet delay + institutional
access delay + LAN delay cache
= 2 sec + minutes + milliseconds
1/19/05 (SSL)
Caching example (cont)

origin
Possible solution
servers
❒ increase bandwidth of access
link to, say, 10 Mbps public
Internet
Consequences
❒ utilization on LAN = 15%
❒ utilization on access link = 15%
10 Mbps
❒ Total delay = Internet delay +
access link
access delay + LAN delay
institutional
= 2 sec + msecs + msecs
network
❒ often a costly upgrade
10 Mbps LAN
institutional
cache

1/19/05 (SSL)
30
Caching example (3)
origin
Install cache servers
❒ suppose hit rate is .4 public
Consequence Internet
❒ 40% requests will be satisfied
almost immediately
❒ 60% requests satisfied by
origin server 1.5 Mbps
access link
❒ utilization of access link
reduced to 60%, resulting in institutional
negligible delay (say 10 msec) network
10 Mbps LAN
❒ ave total delay = Internet
delay + access link delay + LAN
delay
= 0.6*(2 secs + 20 msecs) +
institutional
0.4* (0 + 0 + 10 msecs) cache
(note: ballpark calculations,
transmission time on access link not
included?) 2a: Application Layer 61
1/19/05 (SSL)
Conditional GET
❒ Goal: don’t send object if cache server

cache (client) has up-to-date HTTP request msg
cached version If-modified-since:
object
❒ cache (client): specify date <date>
not
of cached copy in HTTP modified
request HTTP response
HTTP/1.0
If-modified-since: 304 Not Modified
<date>
❒ server: response contains no
HTTP request msg
object if cached copy is up- If-modified-since:
to-date: <date> object
HTTP/1.0 304 Not modified
Modified HTTP response
HTTP/1.0 200 OK
<data>
1/19/05 (SSL)
31
Electronic Mail outgoing
message queue
user mailbox
user
Three major components: agent
❒ user agents mail
user
server
❒ mail servers agent
❒ simple mail transfer SMTP mail
protocol: smtp server user
SMTP agent
User Agent
❒ a.k.a. “mail reader” SMTP
mail user
❒ composing, editing, reading agent
server
mail messages
❒ e.g., Outlook, Eudora, pine, user
Netscape Messenger agent
user
❒ outgoing, incoming messages agent
stored on server
1/19/05 (SSL)
Electronic Mail (cont.)

user
Mail Servers agent
❒ mailbox contains incoming mail
user
messages (yet to be read) server
agent
for user
SMTP
❒ message queue of outgoing mail
(to be sent) mail messages server user
❒ smtp protocol to send and

SMTP agent
receive email messages SMTP

❍ client: sending mail mail user
agent
server server
❍ “server”: receiving mail
user
server agent
user
agent

1/19/05 (SSL)
32
Electronic Mail: smtp [RFC 2821]
❒ uses tcp to reliably transfer email msg from client to

server, port 25
❒ direct transfer: sending server to receiving server
❒ three phases of transfer
❍ handshaking (greeting)
❍ transfer of messages
❍ closure
❒ command/response interaction
❍ commands: ASCII text
❍ response: status code and phrase
❒ messages must be in 7-bit ASCII

1/19/05 (SSL)
Scenario: Alice sends message to Bob

1) Alice uses UA to compose 4) SMTP client sends Alice’s
message to message over the TCP
bob@someschool.edu connection
2) Alice’s UA sends message 5) Bob’s mail server places the
to her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent
3) Client side of SMTP opens to read message
TCP connection with Bob’s
mail server
1 mail
mail
server user
user server
2 agent
agent 3 6
4 5

1/19/05 (SSL)
33
Sample smtp interaction
(after TCP connection established)
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
1/19/05 (SSL)
try smtp interaction for yourself:
❒ telnet servername 25
❒ see 220 reply from server
❒ enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client
(reader)

1/19/05 (SSL)
34
smtp: final words
❒ smtp uses persistent Comparison with http
connections
❒ http: pull
❒ smtp requires that
message (header & body) ❒ email: push
be in 7-bit ascii ❒ both have ASCII
❒ certain character strings command/response
are not permitted in interaction, status codes
message (e.g., CRLF.CRLF).
Thus message has to be ❒ http: each object is
encoded (e.g., into base-64 encapsulated in its own
or quoted printable) response message
❒ smtp server uses ❒ smtp: multiple objects
CRLF.CRLF to determine message sent in a multipart
end of message message

1/19/05 (SSL)
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
commands
❒ body
❍ the “message”, ASCII
characters only

1/19/05 (SSL)
35
Message format: multimedia extensions
❒ MIME: multimedia mail extension, RFC 2045, 2056
❒ additional lines in msg header declare MIME content
type
From: alice@crepes.fr
MIME version To: bob@hamburger.edu
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data

1/19/05 (SSL)
MIME types
Content-Type: type/subtype; parameters
Text Video
❒ example subtypes: plain, ❒ example subtypes: mpeg,
html quicktime
Image
❒ example subtypes: jpeg,
Application
gif ❒ other data that must be
processed by reader
before “viewable”
Audio
❒ example subtypes:
❒ exampe subtypes: basic
(8-bit mu-law encoded), msword, octet-stream
32kadpcm (32 kbps
coding)

1/19/05 (SSL)
36
Multipart Type
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Dear Bob, Please find a picture of a crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
Do you want the recipe?

1/19/05 (SSL)
Mail access protocols

SMTP SMTP POP3 or user
user
agent IMAP agent
sender’s mail receiver’s mail

server server
❒ SMTP: delivery to mail servers

❒ Mail access protocol: retrieval from mail server
❍ POP3: Post Office Protocol version 3 [RFC 1939]
• authorization (agent <-->server) and download
❍ IMAP: Internet Mail Access Protocol [RFC 1730]
• allows organizing stored msgs in folders on mail server
• more features (keeps user state across sessions)
❒ Brower-based email services
❍ http used for sending and retrieval, eg. Hotmail
1/19/05 (SSL)
37
P2P file sharing
❒ Alice chooses one of the
peers, Bob.
Example
❒ File is copied from Bob’s
❒ Alice runs P2P client
PC to Alice’s notebook:
application on her
HTTP
notebook computer
❒ While Alice downloads
❒ Intermittently
from Bob, other user
connects to Internet;
may download from
gets new IP address
Alice.
for each connection
❒ Alice’s notebook is both
❒ Asks for “Hey Jude”
a Web client and a
❒ Application displays transient Web server.
other peers that have
All peers are servers =
copy of Hey Jude.
highly scalable!

1/19/05 (SSL)
P2P: centralized directory

Bob
original “Napster” design centralized
1) when peer connects, it directory server
1
informs central server: peers
❍ IP address 1
❍ content
1 3
2) Alice queries for “Hey
2
Jude” 1
3) Alice requests file from

Bob
Alice

1/19/05 (SSL)
38
P2P: problems with centralized directory
❒ Single point of failure file transfer is

❒ Performance decentralized, but
bottleneck locating content is
❒ Copyright
highly centralized
infringement

1/19/05 (SSL)
Query flooding: Gnutella

❒ fully distributed overlay network: graph
❍ no central server ❒ edge between peer X
❒ public domain protocol and Y if there’s a TCP
❒ many Gnutella clients connection
implementing protocol ❒ all active peers and
edges constitute overlay
net
❒ an edge is not a physical
link
❒ a peer typically
connected with < 10
overlay neighbors

1/19/05 (SSL)
39
Gnutella: protocol
File transfer:
❒ Query message HTTP
sent over existing TCP
connections
Query
❒ peers forward
QueryHit
Query message
y Qu
❒ QueryHit er ery
Qu it
sent over r yH
e
Qu
reverse
Query
path
QueryHit
Scalability: Qu
er
y
limited scope
flooding
1/19/05 (SSL)
P2P: more on query flooding

Pros Cons
❒ peers have similar ❒ excessive query
responsibilities—no traffic
group leaders ❒ limited scope query
❒ highly decentralized— flooding—may not
no peer maintains find content even
directory info when it’s present
❒ protocols to maintain
overlay network

1/19/05 (SSL)
40
Gnutella: Peer joining
1. Joining peer X must find some other peer in
Gnutella network—use a list of candidate peers
2. X sequentially attempts to make TCP connection
with peers on list until connection setup with Y
3. X sends Ping message to Y; Y forwards Ping
message.
4. All peers receiving Ping message respond with
Pong message
5. X receives many Pong messages. It can then set
up additional TCP connections
Peer leaving: see homework problem

1/19/05 (SSL)
Exploiting heterogeneity: KaZaA
❒ Each peer is either a

group leader or assigned
to a group leader.
❍ TCP connection between
peer and its group leader.
❍ TCP connections between
some pairs of group
leaders.
❒ Group leader tracks the
content in all its ordinary peer
children. group-leader peer
neighoring relationships
in overlay network

1/19/05 (SSL)
41
KaZaA: Querying
❒ Each file has a hash and a descriptor
❒ Client sends keyword query to its group
leader
❒ Group leader responds with matches
❍ peers that have files whose descriptors match keywords
❒ If group leader forwards query to other
group leaders, they respond with matches
❒ Client then selects files for download
❍ HTTP requests using hash as identifier sent to
peers holding desired file
1/19/05 (SSL)
KaZaA tricks
❒ Request queueing
❍ Peer can be configured to limit the number of
simultaneous uploads to any value
❍ Requests in excess of limit join a local queue
❒ Incentive priorities
❍ Higher queueing priority to users who have uploaded
more files in the past than they have downloaded
❒ Parallel downloading
❍ Use byte-range header of HTTP to request different
portions of a file from different peers

1/19/05 (SSL)
42

Application Layer: Goals

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Application Layer: Goals

Diunggah oleh

Hak Cipta:

Format Tersedia

Application Layer

Goals: ❒ learn about protocols

2a: Application Layer 1

Some network apps

❒ P2P file sharing

2a: Application Layer 2

run on different end

not function at app layer

2a: Application Layer 4

but difficult to manage

Hybrid of client-server and P2P

2a: Application Layer 6

How to address processes

2a: Application Layer 9

App-layer protocol defines

2a: Application Layer 10

Transport service requirements of common apps

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

2a: Application Layer 12

2a: Application Layer 13

Internet apps: their protocols and transport

e-mail smtp [RFC 2821] TCP

2a: Application Layer 14

2a: Application Layer 15

2a: Application Layer 16

2a: Application Layer 17

Socket API for TCP (BSD Unix)

TCP create socket,

send request using

Socket programming with UDP

UDP: no “connection” between

2a: Application Layer 20

2a: Application Layer 21

UDP Client/server interaction (in Java)

create socket, create socket,

2a: Application Layer 22

2a: Application Layer 23

2a: Application Layer 24

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

Client wants IP address for www.amazon.com; 1st approx:

DNS: Root name servers

2a: Application Layer 26

❒ Authoritative DNS servers: organization’s

2a: Application Layer 27

Local Name Server

2a: Application Layer 28

local DNS server

authoritative DNS server

2a: Application Layer 29

Recursive queries root DNS server

2a: Application Layer 31

2a: Application Layer 33

DNS protocol, messages

Name, type fields

2a: Application Layer 34

(networkutopia.com, dns1.networkutopia.com, NS)

❒ Put in authoritative server Type A record for

2a: Application Layer 35

ftp: the file transfer protocol

FTP file transfer

❒ transfer file to/from remote host