Professional Documents
Culture Documents
Application Layer
2: Application Layer 1
Some network apps
e-mail voice over IP
web real-time video
instant messaging conferencing
remote login grid computing
P2P file sharing
multi-user network
games
streaming stored video
clips
2: Application Layer 2
Creating a network app application
transport
network
data link
2: Application Layer 4
Client-server architecture
server:
always-on host
permanent IP address
server farms for
scaling
clients:
communicate with server
client/server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other
2: Application Layer 5
Pure P2P architecture
no always-on server
arbitrary end systems
directly communicate peer-peer
peers are intermittently
connected and change IP
addresses
2: Application Layer 6
Hybrid of client-server and P2P
Bit torrent
Skype
Instant messaging
2: Application Layer 7
Processes communicating
What is a process? Client process: process
From OS knowledge that initiates
inter-process communication
communication Server process: process
Process creative
that waits to be
contacted
Process University
applications with P2P
In this course architectures
exchanging Having client and
messages server processes?
Message
process sends/receives
host or host or
server server
messages to/from its
socket controlled by
app developer
socket analogous to mail process process
controlled
by OS
2: Application Layer 9
What transport service does an app
need?
Data loss / Reliable data transfer
Throughput
Timing
Security
2: Application Layer 10
Transport service requirements of common apps
file transfer
e-mail
Web documents
real-time audio/video
stored audio/video
interactive games
instant messaging
2: Application Layer 11
Transport service requirements of common apps
2: Application Layer 12
Internet transport protocols services
Application Underlying
Application layer protocol transport protocol
2: Application Layer 14
Application-Layer Protocols
We know that a socket is used to send
network data
How these data are constructed?
2: Application Layer 15
App-layer protocol defines
Types of messages Public-domain protocols:
exchanged, defined in RFCs
e.g., request, response allows for
Message syntax: interoperability
what fields in messages &
e.g., HTTP, SMTP
how fields are delineated
Proprietary protocols:
Message semantics
meaning of information in
e.g., Skype
fields
Rules for when and how
processes send &
respond to messages
2: Application Layer 16
Distributed applications
Web and HTTP
File transfers protocol
Mail
DNS
P2P applications
2: Application Layer 17
Web and HTTP
A 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
2: Application Layer 18
HTTP overview
HTTP: hypertext
transfer protocol
Webs application layer PC running
protocol Explorer
client/server model
client: browser that
requests, receives, Server
displays Web objects running
Apache Web
server: Web server
server
sends objects in
response to requests
Mac running
Navigator
2: Application Layer 19
HTTP overview (continued)
Uses TCP: HTTP is stateless
client initiates TCP server maintains no
connection (creates socket) information about
to server, port 80 past client requests
aside
Protocols that maintain
state are complex!
past history (state) must
be maintained
if server/client crashes,
their views of state may
be inconsistent, must be
reconciled
2: Application Layer 20
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
between client and
server.
2: Application Layer 21
Nonpersistent HTTP
(contains text,
Suppose user enters URL references to 10
www.someSchool.edu/someDepartment/home.index jpeg images)
time
2: Application Layer 22
Nonpersistent HTTP (cont.)
2: Application Layer 23
Non-Persistent HTTP: Response time
Definition of RTT: time for
a small packet to travel
from client to server
and back. initiate TCP
connection
Response time: RTT
one RTT to initiate TCP request
file
connection time to
RTT
transmit
one RTT for HTTP file
request and first few file
received
bytes of HTTP response
to return time time
file transmission time
total = 2RTT+transmit time
2: Application Layer 24
Persistent HTTP
2: Application Layer 25
HTTP request message
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
2: Application Layer 26
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
2: Application Layer 27
HTTP response message
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
2: Application Layer 28
Trying out HTTP (client side) for yourself
2: Application Layer 29
Cookies: keeping state
client server
ebay 8734
usual http request msg
Amazon server
cookie file usual http response creates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
one week later: usual http response msg action backend
database
access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
spectific
usual http response msg action
2: Application Layer 30
Web caches (proxy server)
Goal: satisfy client request without involving origin server
2: Application Layer 32
No caching
Assumptions origin
average object size =
servers
1,000,000 bits public
avg. request rate from Internet
institutions browsers to
origin servers = 15/sec
delay from institutional 15 Mbps
router to any origin server access link
and back to router = 2 sec institutional
network
Consequences 100 Mbps LAN
institutional
Not good solution for the
cache
future
2: Application Layer 34
Solution 2: caching
origin
possible solution: install servers
cache public
suppose hit rate is 0.4 Internet
consequence
40% requests will be
satisfied almost immediately
15 Mbps
60% requests satisfied by
access link
origin server
10 msec for LAN access institutional
delay network
100 Mbps LAN
total avg delay
= Internet delay + access
delay + LAN delay
institutional
= 0.4 * 0.01 + 0.6 (2 + 0.01) cache
2: Application Layer 35
Caching summery
No caching
2 sec + minutes + milliseconds
2: Application Layer 36
Conditional GET and Caching
S: HTTP/1.1 200 OK
Date: Sat, 7 Jul 2007 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 4 Jul 2007 9:23:24
Content-Type: image/gif
(data)
2: Application Layer 39
FTP: separate control, data connections
TCP control connection
FTP client contacts FTP server port 21
at port 21, TCP is transport
protocol TCP data connection
FTP port 20 FTP
client server
2: Application Layer 40
FTP commands, responses
2: Application Layer 41
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., Eudora, Outlook, elm, user
Mozilla Thunderbird agent
user
outgoing, incoming messages agent
stored on server
2: Application Layer 42
Electronic Mail: mail servers
user
Mail Servers agent
mailbox contains incoming mail
user
messages for user server
agent
message queue of outgoing
SMTP
(to be sent) mail messages mail
server user
SMTP protocol between mail
servers to send email SMTP agent
messages SMTP
client: sending mail mail user
agent
server server
server: receiving mail
user
server agent
user
agent
2: Application Layer 43
Electronic Mail: SMTP [RFC 2821]
2: Application Layer 44
Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alices
message and to message over the TCP
bob@someschool.edu connection
2) Alices UA sends message 5) Bobs mail server places the
to her mail server; message message in Bobs mailbox
placed in message queue 6) Bob invokes his user agent
3) Client side of SMTP opens to read message
TCP connection with Bobs
mail server
1 mail
mail
server user
user server
2 agent
agent 3 6
4 5
2: Application Layer 45
Sample SMTP interaction
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
2: Application Layer 46
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)
2: Application Layer 47
DNS: Domain Name System
2: Application Layer 48
DNS
Why not centralize DNS?
single point of failure
traffic volume
distant centralized
database
maintenance
doesnt scale!
2: Application Layer 49
Types of DNS servers
Root Servers:
Entry access server
Top-level domain (TLD) servers:
responsible for com, org, net, edu, etc, and all
top-level country domains uk, fr, ca, jp.
Authoritative DNS servers:
organizations DNS servers
can be maintained by organization or service
provider
2: Application Layer 50
DNS: Root name servers
http://en.wikipedia.org/wiki/Root_nameserver
Duplicated root servers
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)
13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
2: Application Layer 51
Distributed, Hierarchical Database
Root DNS Servers
2: Application Layer 53
DNS name root DNS server
resolution example
2
Host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
gaia.cs.umass.edu 5
gaia.cs.umass.edu
2: Application Layer 54
DNS name
resolution example root DNS server
recursive query: 2 3
puts burden of name 6
7
resolution on
TLD DNS server
contacted name
server
heavy load? local DNS server
dns.poly.edu 5 4
1 8
gaia.cs.umass.edu
2: Application Layer 55
http://network-tools.com/nslook/Default.asp
http://en.wikipedia.org/wiki/List_of_DNS_record_types
DNS records
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
www.ibm.com is really
Type=NS
servereast.backup2.ibm.com
name is domain (e.g.
value is canonical name
foo.com)
value is hostname of
Type=MX
authoritative name
value is name of mailserver
server for this domain
associated with name
2: Application Layer 56
Inserting records into DNS
example: new startup Network Utopia
register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
provide names, IP addresses of authoritative name server
(primary and secondary)
registrar inserts two RRs into com TLD server:
2: Application Layer 57
Pure P2P architecture
Three topics:
File distribution
Distributed Hash Table
(DHT) peer-peer
Case Study: Skype
2: Application Layer 58
File Distribution: Server-Client vs P2P
Question : How much time to distribute file
from one server to N peers?
us: server upload
bandwidth
Server
ui: peer i upload
u1 d1 u2 bandwidth
us d2
di: peer i download
File, size F bandwidth
dN
Network (with
uN abundant bandwidth)
2: Application Layer 59
File distribution time: server-client
Server
server sequentially F u1 d1 u2
sends N copies: us d2
Time to distribute F
to N clients using = dcs = max { NF/us, F/min(di) }
i
client/server approach
increases linearly in N
(for large N) 2: Application Layer 60
File distribution time: P2P
Server
server must send one
F u1 d1 u2
copy: F/us time us d2
downloaded (aggregate)
fastest possible upload rate: us + ui
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
N
2: Application Layer 62
P2P: centralized index
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
Alice
2: Application Layer 63
P2P: problems with centralized directory
2: Application Layer 64
Query flooding
fully distributed overlay network: graph
no central server edge between peer X
used by Gnutella and Y if theres a TCP
Each peer indexes the connection
files it makes available all active peers and
for sharing (and no edges form overlay net
other files)
edge: virtual (not
physical) link
given peer typically
connected with < 10
overlay neighbors
2: Application Layer 65
Query flooding
File transfer:
Query message HTTP
sent over existing TCP
connections
Query
peers forward
QueryHit
Query message
QueryHit
sent over
reverse
path
Query
QueryHit
Scalability:
limited scope
flooding
2: Application Layer 66
Hierarchical Overlay
between centralized
index, query flooding
approaches
each peer is either a
super node or assigned to
a super node
TCP connection between
peer and its super node.
TCP connections between
some pairs of super nodes. ordinary peer
2: Application Layer 67
P2P Case study: Skype
Skype clients (SC)
inherently P2P: pairs
of users communicate.
proprietary Skype
application-layer login server Supernode
protocol (inferred via (SN)
reverse engineering)
hierarchical overlay
with SNs
Index maps usernames
to IP addresses;
distributed over SNs
2: Application Layer 68
Peers as relays
Problem when both
Alice and Bob are
behind NATs.
NAT prevents an outside
peer from initiating a call
to insider peer
Solution:
Using Alices and Bobs
SNs, Relay is chosen
Each peer initiates
session with relay.
Peers can now
communicate through
NATs via relay
2: Application Layer 69
Distributed Hash Table (DHT)
DHT = distributed P2P database
Database has (key, value) pairs;
key: ss number; value: human name
key: content type; value: IP address
15 3
4
12
5
10
8
Each peer only aware of immediate successor
and predecessor.
Overlay network
Circle DHT (2)
1110 0100
1110
1100
1110
1110 0101
Define closest 1110
as closest 1010
successor 1000
Circular DHT with Shortcuts
1 Whos resp
for key 1110?
3
15
4
12
5
10
8
Each peer keeps track of IP addresses of predecessor,
successor, short cuts.
Reduced from 6 to 2 messages.
Possible to design shortcuts so O(log N) neighbors, O(log
N) messages in query
Peer Churn
1
To handle peer churn, require
P2P FTP
Download instruction
from book website
Do HTTP lab
Do DNS lab
2: Application Layer 79